Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] variant with tuple arg in pattern match?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-04-08 (23:57)
From: Brian Rogoff <bpr@b...>
Subject: Re: [Caml-list] variant with tuple arg in pattern match?
On Sun, 8 Apr 2001, Pierre Weis wrote:
> > On 06-Apr-2001, Xavier Leroy <> 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, 

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  Archives: