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
Allow extension nodes after "type", e.g. "type%foo" #6623
Comments
Comment author: @gasche I have conflicting opinions about the proposed use-case but I ultimately think it is a good idea. Against: I do not want -ppx to become a trash bin of all not-popular-enough language change proposals. If we were to constantly use %stuff in practice, that would lead us to an ugly language with a patchwork syntax, making "minimally invasive" choices instead of picking good designs. In favor: ppx or camlp4 extensions can be a good way to gain practical experience with a language feature, and help pressure people into including support in the language proper. We may never have got local module opening if it wasn't for Alain's camlp4 extension. My uneasiness with the %nonrec example is that to me it clearly pertains to the core language semantics rather than a form of preprocessing. There is no reason to prefer having it as a ppx other than politics (and compatibility, etc., which I'll just call politics for now). On the contrary, I'm more comfortable with using -ppx for monadic syntaxes (eg. let%lwt) that really are a form of syntactic preprocessing by design. I think in the specific example of %nonrec, ppx is not the best choice: we already have practical experience using it (thanks to type_conv). What we should do is seriously discuss adding it as a keyword eventually, for example by emitting deprecation warnings on the use of nonrec as an identifier in the next release. This PR item is not the right place for this, though. I'm in favor of the change for the "In favor" reasons; it will also benefit other use-cases that we haven't thought of yet. |
Comment author: @whitequark I completely agree that it should be in the core language, and that doing this via ppx is ad-hoc. However, I got the impression from 6016 that there is 1) no consensus on how the feature should look 2) likely no way to integrate it without a major version bump. So I do not hold my breath for 6061 to be resolved in a reasonable timeframe, if at all. |
Comment author: @alainfrisch I assume that "type%foo ..." would be equivalent to "[%%foo type ...]". And that the same would apply to all kind of sig/struct items (except the "eval" str items). Is that right? |
Comment author: @whitequark Yes. |
Comment author: @Drup We allow the shortcut syntax on a certain number of keywords (let, begin, for, ....), I think that for uniformity, it should be allowed on all of them. |
Comment author: @damiendoligez @Drup: agree For the specific case of %nonrec, adding it now does not preclude adding a keyword later, so I'm in favor. |
Comment author: @alainfrisch
I've a slight concern about allowing the short syntax on structure items. For expressions, "begin%foo ... end" maps to "[%foo begin ... end]". The "%foo" part is identical. For structure items, the long syntax is not "%foo" but "%%foo". Should the short form then be "type%%foo ..."? There is also the question on whether the extension marker should be local to the whole structure item, which can contain multiple definitions (e.g. "type ... and ..."), or to each definitions. Since attributes can be attached to each definition (not to the whole item), it would be coherent for the short form to be local to each definitions, so we could write: "type%foo t = ... and%bar = ...". Another concern is that currently, the payload cannot be a signature. If we add signatures as another form of possible payload, with a dedicated syntax (say: [%%foo sig ....]), then it's not clear what "type%foo t = ..." should be mapped to in signatures: [%%foo type t = ...] or [%%foo sig type t = ...])? This problem goes away if we merge structure/signature items (as I suggest in another ticket). I'm also not yet convinced that extension node is the proper mechanism for the current discussion, for two reasons:
Imagine that we later want to introduce a "local" modifier, which drops the current declaration from the signature inferred for the current structure. Would we write: type%nonrec%local or type%local%nonrec ? (The short-form currently doesn't support multiple extensions, but it does support multiple attributes.) |
Comment author: @Drup
I don't really mind either way. It's useful for distinguishing the two kind of let and it's a bit more consistent, so maybe it's a good idea.
Coherent with what ? It's not possible with the long form as far as I know.
That's precisely why I like this solution. :) |
Comment author: @Octachron This was fixed by #342 (and 482). |
Original bug ID: 6623
Reporter: @whitequark
Status: resolved (set by @Octachron on 2016-12-27T16:59:25Z)
Resolution: open
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)
Related to: #6016 #6586
Monitored by: @Drup @hcarty
Bug description
This is intended as a solution to #6016.
This would allow to write a syntax extension implementing the equivalent of what type_conv currently does with "type nonrec" as "type%nonrec" while not introducing any new keywords, which should satisfy everyone.
The text was updated successfully, but these errors were encountered: