Re: [Caml-list] variant with tuple arg in pattern match?

[Brian Rogoff <bpr@best.com>]

On Sun, 8 Apr 2001, Pierre Weis wrote:
> > On 06-Apr-2001, Xavier Leroy <Xavier.Leroy@inria.fr> wrote:
> > > 
> > > Frankly, I think there is no point in maintaining the illusion that
> > > datatype constructors are either nullary (constant) or unary.  The
> > > only efficient implementation model is N-ary constructors, so let's
> > > reflect this in the language.
> > 
> > Sounds good to me.  Now, for consistency, shouldn't you do the same
> > for function arguments? ;-)
> 
> I would suggest the other way round: as we already did for functions,
> we should prefer the curried syntax for constructors.

Good, I was starting to get worried. Someone earlier was complaining about 
Caml's curriedness vs SML's tupledness. I've been porting a bunch of code 
from SML to Caml lately, and of course this issue comes up constantly. 
There is probably a strong issue of familiarity involved, but I actually 
much prefer the Caml way.

> I suggest to explicitely annotate the constructor definitions as in:
> 
> type t =
> | C : int -> int -> t

Now that's an interesting idea! 

> This notation is explicit, intuitive, and allows refined type checking
> in some cases (for instance
> type 'a t = C : int -> bool -> (int * bool) t).
> 
> Last but not least, this suggestion is a pure extension of the actual
> syntax, compatible with the current notations. (We can still allow the
> form ``C of ty'' as a short hand for C of ty -> t).

You meant C : ty -> t of course. Getting back to the original problem
and confusing cases, would you still want the shorthands for the cases, 
say 

type t = C : int -> int -> t <=> type t = C of int * int ?
type t = C : int * int -> t  <=> type t = C of (int * int)

to be fixed so that the confusions don't arise anymore, or would you just 
want to deprecate the earlier notations?

-- Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr