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 NAA07693; Tue, 1 Oct 2002 13:37:54 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id NAA07795 for ; Tue, 1 Oct 2002 13:37:53 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g91Bbp517379; Tue, 1 Oct 2002 13:37:51 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id NAA07738; Tue, 1 Oct 2002 13:37:50 +0200 (MET DST) Date: Tue, 1 Oct 2002 13:37:50 +0200 From: Xavier Leroy To: Dan Schmidt Cc: caml-list@inria.fr Subject: Re: [Caml-list] Design advice Message-ID: <20021001133750.A7346@pauillac.inria.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from dfan@dfan.org on Fri, Sep 27, 2002 at 12:47:35PM -0400 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Dan Schmidt wrote: > One has to do with making the equivalent of an enum in C. Say I'm > implementing a deck of cards for a card game. There are four suits, > and none of them have any special properties (this isn't a game like > bridge where different suits are treated differently). I could do > type suit = Spades | Hearts | Diamonds | Clubs > but this seems a little heavyweight; it seems weird to perform pattern > matching on values that really have no semantic importance other than > the fact that they are different from each other. It's not like I'm > going to have any code that does one thing when given the 3 of Spades > and another thing when given the 3 of Hearts. The other issue is that > it is mildly annoying to, for example, write a compare function to be > used inside a struct that implements the OrderedType signature (e.g., > if I want to have a Set of cards). As others mentioned, the generic comparison functions (=, <, compare, etc) work just fine on datatypes, and provide you with a suitable ordering function for sets or maps. > Finally, is there any type in the library that functions like an > immutable array? I would like to have an indexable bunch of values > but use it in a purely functional way. You can use maps (module Map from the standard library), using integers as keys. > I could always just use > Arrays and copy them before updating, but if there's already an > idiomatic type to use I'd prefer to use that. Actually, there is a better way: "version arrays". The idea is to go ahead and update in place an array, but record the overwritten array element in a separate data structure. Thus, you can access the latest version of the array in constant time, and earlier versions a bit more slowly. I can't point you to an actual implementation, but no doubt others on this list can. John Malecki wrote: > This thread reminds me to ask if are there any guarantees for ordering > of variant types? Although the implementation indicates that with > type card = Number of int | Jack | Queen | King | Ace > Jack < Queen and Queen < King it also says that Ace < Number 0. I can > see what is going on with the implementation. I'm curious if there > are any ordering guarantees that I can take advantage of? Since the > documentation is silent on this point I doubt it. > Oh, It does seems as if tuples, arrays and lists are always compared > "from left to right". This can be handy when sorting multi- > dimensional data. This seems like a "more natural" ordering than for > variants but, once again, can this ordering be guaranteed for all > ocaml programs? The current implementation works exactly as you described. I'm reluctant to specify the ordering of variant and product types in more details, as it depends very much on the data representations chosen by the compiler, which might change one day (?). It is however very likely that enumerated datatypes (all constructors are constant) will always be ordered left-to-right, and that tuples and arrays will always be ordered lexicographically left-to-right. Chris Hecker wrote: > type card = Number of int | Jack | Queen | King | Ace > On a related note, for Xavier et al., why wasn't Number's field 0 assigned > to the same counter as the int of the non-argument constructors? In other > words, why isn't there a single incrementing int id from left to right, > regardless of arguments? Caml Light worked as you suggest (only one "counter" for constant and non-constant constructors). The main reason for having two different "counters" in OCaml is that integer tags for non-constant constructors must be less than 246 (i.e. fit in 8 bits, with a few reserved values). Hence, in Caml Light, no datatype could have more than 246 constructors, while in OCaml a datatype can have arbitrarily many constant constructors, it's only the non-constant constructors that are limited in number. - Xavier Leroy ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners