It sounds like this has nothing to do with polymorphic variants not requiring a type definition.

I agree it's an ugly hack, but one that seems to accomplish something of value. There are two distinctions that I know of between single argument tuple constructors and mult-argument constructors:

1. Memory layout is different (Is this still the case)?
2. First-classness of arguments is different. With a single argument tuple, the contents can be passed around and then finally placed into the constructor without any overhead of destructuring/restructuring.

Both of these seem like desirable controls to have and possibly justifies the existence of having two modes.
Under that assumption, having some way to designate in the parse tree which is intended (at the pattern or expression level) seems like a good idea - and even if that mechanism is the ugly `explicit_arity` hack. So I understand the justification for the current state of the world. I'm curious why there is not some way to achieve the same with polymorphic variants (even if that is also a hack). Are you saying it was simply because time has not permitted it? Looking deeper, it seems polymorphic variants are incapable of accepting multiple arguments and only ever accept a single tuple (which is therefore allowed to be first class).

I do wish OCaml used the revised syntax's syntactic distinction between the two modes which is what I'm currently experimenting with.

On Sat, Jan 24, 2015 at 12:52 AM, Gabriel Scherer <gabriel.scherer@gmail.com> wrote:
explicit_arity is an ugly hack. It is used by camlp[45] (whose revised
syntax has a superior currified constructor-parameter syntax and is
thus never confused about arities) to convert its internal AST into
the OCaml parse tree. It is not meant to be used by end-users, only by
camlp5 as a code-producing tool.

You ask why this was not extended to polymorphic variant. There was no
need, so nobody worked on it. Besides, I suspect making polymorphic
variant more complex is a bad idea -- and am quite certain relying on
an attribute there is a bad idea.


On Fri, Jan 23, 2015 at 10:04 AM, Jordan W <jordojw@gmail.com> wrote:
> My understanding was that this "explicit_arity" attribute allows precisely
> that - the capability to implement a specific syntax to distinguish between
> multiple arguments and just one argument (that may coincidentally be a
> tuple). My question is why this capability is not extended to polymorphic
> variants in the same way it has been extended to standard variant types.
>
> On Fri, Jan 23, 2015 at 12:03 AM, Jacques Garrigue
> <garrigue@math.nagoya-u.ac.jp> wrote:
>>
>> The answer is simple: polymorphic variants can only accept one argument
>> (which may of course be a tuple). The other behavior would have required
>> a specific syntax for multi-parameter polymorphic variants, since there is
>> no information associated to the constructor for them.
>>
>> Jacques Garrigue
>>
>> On 2015/01/23 15:53, Jordan W wrote:
>> >
>> > The OCaml compiler allows distinguishing between variants that accept a
>> > single tuple and variant types that accept several parameters. What looks
>> > like a variant type accepting a tuple, is actually the later:
>> >
>> > type x = TwoSeparateArguments of int * int
>> > let tuple = (10,10)
>> > let thisWontWork = TwoSeparateArguments tuple;;
>> > >> Error: The constructor TwoSeparateArguments expects 2 argument(s),
>> > >> but is applied here to 1 argument(s)
>> >
>> > (* Notice the extra parens around the two ints *)
>> > type x = OneArgumentThatIsATuple of (int * int)
>> > let thisActuallyWorks = OneArgumentThatIsATuple tuple
>> >
>> > The extra parens distinguish at type definition time which of the two is
>> > intended.
>> >
>> > But OCaml does some automatic massaging of the data that you supply to
>> > constructor values.
>> > let _ = OneArgumentThatIsATuple (4, 5)
>> > let _ = TwoSeparateArguments (4, 5)
>> >
>> > No extra parens are required in this case. But OCaml does give you the
>> > ability to annotate patterns and expressions with an "explicit_arity"
>> > attribute which allows syntactic distinction between supplying two separate
>> > parameters vs. one that happens to be a tuple. This is important for other
>> > parser extensions that wish to treat the two distinctly. What OCaml allows
>> > (explicit_arity attribute) works well enough.
>> >
>> > The only problem is that there doesn't seem to be a way to utilize the
>> > same explicit_arity attributes with polymorphic variants. Such attributes
>> > are not acknowledged by the type system. Is this intended?
>> >
>> > Taking a quick look at typecore.ml, explicit_arity appears to be
>> > acknowledged on standard constructors but not polymorphic variants.
>> >
>> > https://github.com/ocaml/ocaml/blob/6e85c2d956c8fd5b45acd70a27586e44bb3a3119/typing/typecore.ml
>> >
>> > It seems these should be brought to consistency. I will file a mantis
>> > issue unless anyone believes this is intended.
>> >
>> > Thank you in advance.
>> >
>> > Jordan
>> >
>> >
>>
>>
>