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

Allow extension nodes after "type", e.g. "type%foo" #6623

Closed
vicuna opened this issue Oct 22, 2014 · 9 comments
Closed

Allow extension nodes after "type", e.g. "type%foo" #6623

vicuna opened this issue Oct 22, 2014 · 9 comments

Comments

@vicuna
Copy link

vicuna commented Oct 22, 2014

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.

@vicuna
Copy link
Author

vicuna commented Oct 22, 2014

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.

@vicuna
Copy link
Author

vicuna commented Oct 22, 2014

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.

@vicuna
Copy link
Author

vicuna commented Nov 3, 2014

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?

@vicuna
Copy link
Author

vicuna commented Nov 3, 2014

Comment author: @whitequark

Yes.

@vicuna
Copy link
Author

vicuna commented Nov 28, 2014

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.

@vicuna
Copy link
Author

vicuna commented Dec 17, 2014

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.

@vicuna
Copy link
Author

vicuna commented Dec 18, 2014

Comment author: @alainfrisch

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.

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:

  1. First, this is a case of a feature which has already been field tested, which has strong supporters, and which has no reason to be "implementation" dependent. It really looks like a language feature. While extension nodes are great to experiment with such features, this should be done outside the compiler or in the compiler, but only during development for quicker experiment (e.g. in special feature branches). When the feature is officially accepted, it deserves a proper syntax in the language and careful discussion about it's exact interpretation.

  2. nonrec seems to be a modifier on the type definition, which could be combined with other such modifiers to be introduced later (or e.g. with client/server modifiers for Ocsigen). Extensions are intended to be used to embed in OCaml program some fragments of foreign languages (whose syntax happens to be encoded in OCaml syntax, and which might refer to proper OCaml sub-fragments) or "new language features" which are mapped to existing ones; typically: special forms of pattern matching, query languages, etc. Modifying existing constructions without fundamentally changing their meaning should rather be done with attributes.

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.)

@vicuna
Copy link
Author

vicuna commented Dec 18, 2014

Comment author: @Drup

For structure items, the long syntax is not "%foo" but "%%foo". Should the short form then be "type%%foo ..."?

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.

it would be coherent for the short form to be local to each definitions, so we could write: "type%foo t = ... and%bar = ...".

Coherent with what ? It's not possible with the long form as far as I know.

This problem goes away if we merge structure/signature items (as I suggest in another ticket).

That's precisely why I like this solution. :)

@vicuna
Copy link
Author

vicuna commented Dec 27, 2016

Comment author: @Octachron

This was fixed by #342 (and 482).

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

1 participant