From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id BAA14152; Mon, 9 Apr 2001 01:57:36 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id BAA14140 for ; Mon, 9 Apr 2001 01:57:35 +0200 (MET DST) Received: from shell5.ba.best.com (shell5.ba.best.com [206.184.139.136]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f38NvXb28068; Mon, 9 Apr 2001 01:57:33 +0200 (MET DST) Received: from localhost (bpr@localhost) by shell5.ba.best.com (8.9.3/8.9.2/best.sh) with ESMTP id QAA09049; Sun, 8 Apr 2001 16:57:27 -0700 (PDT) Date: Sun, 8 Apr 2001 16:57:27 -0700 (PDT) From: Brian Rogoff To: Pierre Weis cc: caml-list@inria.fr Subject: Re: [Caml-list] variant with tuple arg in pattern match? In-Reply-To: <200104081945.VAA09757@pauillac.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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, 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