Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

a backward-compatible way of adding new syntactic construct #6037

Closed
vicuna opened this issue Jun 8, 2013 · 1 comment
Closed

a backward-compatible way of adding new syntactic construct #6037

vicuna opened this issue Jun 8, 2013 · 1 comment
Assignees

Comments

@vicuna
Copy link

vicuna commented Jun 8, 2013

Original bug ID: 6037
Reporter: @bobzhang
Assigned to: @alainfrisch
Status: closed (set by @xavierleroy on 2015-12-11T18:19:32Z)
Resolution: won't fix
Priority: normal
Severity: minor
Version: 4.01.0+dev
Category: ~DO NOT USE (was: OCaml general)

Bug description

I found that the trunk changed Pexp_open
----- old
Pexp_open of Longident.t loc * expression
----- new
Pexp_open of override_flag * Longident.t loc * expression

How about adding a new constructor instead
Pexp_open_bang of Longident.t loc * expression
The main benefit is to avoid unnecessary breaking other compiler dependent tools?

Thanks

@vicuna
Copy link
Author

vicuna commented Jun 9, 2013

Comment author: @alainfrisch

If we had followed this approach to make the Parsetree backward-compatible for previous evolutions of the Parsetree, we would have ended up already with a mess (many duplicated constructors, for no good conceptual reason). Not even mentioning the recent changes introduced with the "bin-annot" branch (which changes most constructors) and the forthcoming "extension_points" (idem). Tools which use directly the Parsetree or other internal modules of the compiler should be prepared for such changes.

For the specific case you cite, I see it as a good thing that tools matching on the Parsetree need to be adapted explicitly. The author of these tools need to decide whether the new form should also be recognized or not where previously the Pexp_open constructor was used. And adapting the code is rather trivial anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants