Re: [Caml-list] Why must types be always defined at the top level?

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

> 1. Why no eqtypes? The idea of having the type-checker verify that you
> weren't doing equality testing on non-equality-testable types seemed 
> like GOOD thing in SML, and I was surprised to see it gone. 

Eqtypes have been hotly debated even among the SML designers.  My
feeling is that it's not worthwhile to have a special, hard-wired
mechanism in the type checker just for the sake of equality.  There is
a general need to have polymorphic operations that are 1- not defined on
all instantiations of their types, and 2- can be defined differently
on different instantiations.  Haskell type classes are an example of a
*general* mechanism that addresses this need; GCaml's "extentional
polymorphism" is another.  But SML's eqtypes are just not general at all.

> 2. Why no "end" on "let" expressions, i.e., 
> 
>  let a = 3 and b = 2 in a + b;;
> 
> rather than 
> 
>  let a = 3 and b = 2 in a + b end; ?

Ah, syntax...  Without entering in a debate on which syntax is "better",
let me just give an historical reason: there was no "end" on "let"
expressions in the original LCF ML, from which Le_ML, then the first
Caml, then Caml Light, then OCaml derive.  We don't like gratuitous
syntax changes :-)

> 3. Why semicolons for separating list items, so that 
> 
>   [2,3] is interpreted as [(2,3)] ? 

Why not?  Again, I guess this is historical.  Both SML and the various
Camls use two symbols "," and ";" to denote three different things
(tuples, lists and arrays, and sequence).  SML "overloads" the comma
to mean two of these things, Caml overloads the semicolon.

> 4. Why expose the hardware with float (and make it have equality
> testing) rather than continue with "real" (which was not an eqtype, if
> I recally correctly)? 

Unless a language offers exact-precision arithmetic on computable
reals, I strongly object to the use of the word "real" to refer to
what's merely floating-point numbers.  Floats aren't reals by any
stretch of the imagination, and the earlier the programmer realizes
this, the better.  

As to whether equality should be defined on floats, there are pros and
cons.  My standpoint is that it's eventually better to stick to
established standards (that is, IEEE float arithmetic) rather than try
to reinvent a wheel likely to be even squarer than these standards.
Prof. Kahan found it worthwhile to fully define equality over floats;
I'll abide by his wisdom.

- Xavier

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