Version française
Home     About     Download     Resources     Contact us    
Browse thread
Variants & structural ordering
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: michaelgrunewald@y...
Subject: Re: [Caml-list] Variants & structural ordering
"Damien Guichard" <alphablock@orange.fr> writes:

> Hi everybody,
>  
> Typically, when you declare:
>  
> type card =
>   | Card of int
>   | Jack
>   | Queen
>   | King
>   | Ace
>   ;;
>  
> The relation you wish is:
>  
> Card(2) < ...< Card(10) < Jack < Queen < King < Ace
>  
> And that's what you get when using F#.
>  
> However when using OCaml here is what you get:
>  
> Jack < Queen < King < Ace < Card(2) < ...< Card(10)
>  
> And the work-around is:
>  
> type card =
>   | Card of int
>   | Jack of unit
>   | Queen of unit
>   | King of unit
>   | Ace of unit
>   ;;
>  
> Is this a bug or a feature ?
> Will it change in a foreseable future ?

Conventions are always a bit arbitrary, aren't they? To me, the
natural order with cards are:
  Card(7) < Card(8) < Queen < King < Card(10)< Ace < Card(9) < Jack
and
  Card(7) < Card(8) < Card(9) < Jack < Queen < King < Card(10)< Ace
(yes there are two natural orders).

Furthermore, I tried your program on a host whose native charset is
KOBAIA-8 (a weird variation on EBCDIC), hold your breath:
  F# behaves there just like OCaml does on your host, and vice-versa!

Computers are good at doing what they are told to, so why don't you
tell them?

The only purpose of a generic `compare' procedure os the easy use of
`Set.Make' and `Map.Make' with random types, isnt't it? It is very bad
to assume it giving any sensible order on non basic types, you sure
have to define `sensible' yourself.
-- 
Michaël