parsing bug on function types in variant type definitions

[gasche]

The following is rejected as a parse error, but it should be accepted:

type t = Foo of int -> int

[xavierleroy]

Accepting this (without parentheses around the function type) makes the following example ambiguous:

type t = Foo of int -> int * int

Is this Foo of (int -> int) * int (two arguments) or Foo of (int -> (int * int)) (one argument) ?

[damiendoligez]

So we need to change the grammar in the documentation because the current version has this ambiguity.

[gasche]

My expectation would be:

1. parse the right-hand-side of of as a type expression
2. split the toplevel tuple type (if any) into several arguments

This gives a justification for the interpretation (int -> int * int) in your example.

This being said, in the case of int -> int * int it makes sense to fail instead of pick a choice, forcing users to be explicit. The failure is rather confusing on examples that do not contain any tuples. But of course there is no easy way to write simple parsing rules that accept arrow types without tuple types below (except by writing yet another specialized syntactic category for this). So maybe one sensible long-term solution would be to keep failing with an error here, but hopefully with an error message that explains the solution. (I hear that @let-def work on parsing error messages for OCaml has made progress recently, so one can hope.)

[let-def]

I added your example as a test case.

However accepting this input might be nice. There are two difficulties I can think of:

• when parsing the RHS as a type expression, we still need to distinguish Foo of a * b from Foo of (a * b) (not splitting a tuple that was nested on purpose). Even this simple solution needs subtle changes to the grammar
• for generalized constructors, the -> has another meaning. So the grammar of arguments after of and : will differ again in subtle ways.

[craff]

Why not declare the "of" syntax deprecated to keep only the more general syntax of GADT in the future ? OK it is a bit annoying to have to write the result type but a notation like

type a_long_name_to_make_sure_we_know_what_it_means = Foo : (int -> int * int) -> _

could solve that problem for type which have no parameters but have a long name.
I think any simplification of OCaml is welcome ?

[gasche]

No, we don't deprecate simpler, perfectly-fine syntax used all over the place (programs, docs, textbook, wikipedia, whatever) just to work around a parsing ambiguity. The cost of those deprecations is huge and in this case the benfit is razor thin.

[craff]

No, we don't deprecate simpler, perfectly-fine syntax used all over the place (programs, docs, textbook, wikipedia, whatever) just to work around a parsing ambiguity. The cost of those deprecations is huge and in this case the benfit is razor thin.

First, I think that the "of" syntax is shorter but definitevely not simpler when I teach. I actually teach directly GADT syntax nowdays, except for constant constructors. This suggested me a discussion that does not belong here, so I added a topic in ocaml.discuss: https://discuss.ocaml.org/t/simplification-of-ocaml-as-a-design-goal/10210

…

-- Christophe Raffalli tél: +689 87 23 11 48 web: http://raffalli.eu

[github-actions]

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

[gasche]

I don't want to receive further notifications on this issue before we integrate @let-def's work on the parser. In the meantime I propose to close, after tagging with syntax-error-messages (which is morphing into "stuff that would benefit from Fred's work").