Re: [Caml-list] Design advice

[Xavier Leroy <xavier.leroy@inria.fr>]

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