Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006623OCamlOCaml generalpublic2014-10-22 14:252016-12-27 17:59
Reporterwhitequark 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusresolvedResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0006623: Allow extension nodes after "type", e.g. "type%foo"
DescriptionThis 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.
TagsNo tags attached.
Attached Files

- Relationships
related to 0006016closeddim non-recursive type declarations 
related to 0006586closed Short-hand version of attributes on structure items and class fields 

-  Notes
(0012413)
gasche (developer)
2014-10-22 15:02
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.

(0012414)
whitequark (developer)
2014-10-22 15:07
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.

(0012483)
frisch (developer)
2014-11-03 22:41

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?
(0012484)
whitequark (developer)
2014-11-03 22:42

Yes.
(0012590)
drup (reporter)
2014-11-28 18:13

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.
(0012845)
doligez (administrator)
2014-12-18 00:10

@drup: agree

For the specific case of %nonrec, adding it now does not preclude adding a keyword later, so I'm in favor.
(0012852)
frisch (developer)
2014-12-18 10:31

> 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.)
(0012870)
drup (reporter)
2014-12-18 17:14

> 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. :)
(0017047)
octachron (developer)
2016-12-27 17:58

This was fixed by GPR#342 (and 482).

- Issue History
Date Modified Username Field Change
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


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker