RE: [Caml-list] Explicit Arity with Polymorphic Variants

[David Allsopp <dra-news@metastack.com>]

Jordan W wrote:
> David, are you certain that the explicit_arity attribute is only related to type 
> declarations? I do not believe that to be the case. I understand them to apply to
> patterns and expressions as well.

I'm (reasonably) certain that the information it conveys can only ever be useful when you have a type definition. 

> (* Declares a variant that accepts a *single* parameter *)
> type oneArgTuple = OneArg of (int*int)
>
> (* Works because arity is massaged into whatever is necessary and doesn't need to be expressed at parse time. *)
> let OneArg (x,y) = OneArg (1,2)

Because of the type definition. 

> (* But you can *explicitly* enforce arity and tell the type system that this tuple should be treated as multiple arguments *)
> (* That causes this to fail type checking on this tuple pattern! *)
> let (OneArg (x,y) [@explicit_arity]) = OneArg (1,2);;
> >> Error: The constructor OneArg expects 1 argument(s),
> >> but is applied here to 2 argument(s)

Again, because of the presence of a type definition.

> (* Similarly, at parse time, you can tell the parser to parse an expression as being multiple arguments *)
> let result = OneArg (1,2)[@explicit_arity];;
> >> Error: The constructor OneArg expects 1 argument(s),
> >> but is applied here to 2 argument(s)
>
> So the fact that you can inform the parser to treat a tuple as multiple arguments to a Constructor, 
> means that the same should be true of polymorphic variants, but it is not. For example, this type 
> checks but it shouldn't:
>
> let (`MyThing (x,y) [@explicit_arity]) = `MyThing (2,2);;

In this context, if the type-checker chose to look at the @explicit_arity attribute, then it must always return a type error when the tuple is neither singleton nor unit (since polymorphic variants only take one argument) - what's the benefit of this, therefore? (I don't quite follow why you'd want to be getting an explicit type check error when using an *internal* OCaml attribute somewhere where it's not intended - http://caml.inria.fr/svn/ocaml/branches/constructors_with_record3/experimental/frisch/extension_points.txt).


David