|Anonymous | Login | Signup for a new account||2017-02-24 20:21 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006623||OCaml||-OCaml general||public||2014-10-22 14:25||2016-12-27 17:59|
|Priority||normal||Severity||feature||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0006623: Allow extension nodes after "type", e.g. "type%foo"|
|Description||This is intended as a solution to http://caml.inria.fr/mantis/view.php?id=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.
|Tags||No tags attached.|
edited on: 2014-10-22 15:03
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.
edited on: 2014-10-22 15:07
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.
|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?|
|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.|
For the specific case of %nonrec, adding it now does not preclude adding a keyword later, so I'm in favor.
> 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:
(The short-form currently doesn't support multiple extensions, but it does support multiple attributes.)
> 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. :)
|This was fixed by GPR#342 (and 482).|
|2014-10-22 14:25||whitequark||New Issue|
|2014-10-22 14:25||whitequark||Relationship added||related to 0006016|
|2014-10-22 15:02||gasche||Note Added: 0012413|
|2014-10-22 15:03||gasche||Note Edited: 0012413||View Revisions|
|2014-10-22 15:03||gasche||Note Edited: 0012413||View Revisions|
|2014-10-22 15:07||whitequark||Note Added: 0012414|
|2014-10-22 15:07||whitequark||Note Edited: 0012414||View Revisions|
|2014-11-03 22:41||frisch||Note Added: 0012483|
|2014-11-03 22:42||whitequark||Note Added: 0012484|
|2014-11-28 18:13||drup||Note Added: 0012590|
|2014-12-18 00:10||doligez||Note Added: 0012845|
|2014-12-18 00:10||doligez||Assigned To||=> doligez|
|2014-12-18 00:10||doligez||Status||new => confirmed|
|2014-12-18 00:10||doligez||Assigned To||doligez =>|
|2014-12-18 10:31||frisch||Note Added: 0012852|
|2014-12-18 10:36||frisch||Relationship added||related to 0006586|
|2014-12-18 17:14||drup||Note Added: 0012870|
|2016-12-27 17:58||octachron||Note Added: 0017047|
|2016-12-27 17:59||octachron||Status||confirmed => resolved|
|2017-02-23 16:36||doligez||Category||OCaml general => -OCaml general|
|Copyright © 2000 - 2011 MantisBT Group|