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

["John Hughes" <jfh@cs.brown.edu>]

Thanks for the answers.  
> > 1. Why no eqtypes? 
> 
> 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.  

Agreed. One of our students, a year ago, after being told about
eqtypes, asked "is there something like 'numtype' too, so
that we can tell whether it's OK to do arithmetic?" (Recall
this was SML, where "+" is overloaded.) It was clear that
the idea *behind* eqtypes should be extended ... but the alternative,
of removing them entirely, is just as consistent, I suppose. 

> > 2. Why no "end" on "let" expressions, i.e.,
> [History]
> 
> > 3. Why semicolons for separating list items, so that
> > 
> >   [2,3] is interpreted as [(2,3)] ? 
> 
> [Why not?]

Fair enough. 
 
> > 4. Why expose the hardware with "float" ...
> 
> 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.  

This from someone who uses "int" to mean something other than
"integer"! :-)

> Floats aren't reals by any stretch of the imagination, and 
> the earlier the programmer realizes this, the better.  

Agreed. And deference to Bill Kahan is generally a good idea. 

---
I have one more question, though: 

5. Why can I no longer type-annotate things I've written, so that

let f x y z = (x = y) & (y = z)

defines a function applicable to ALL types? I actually *liked*
being able to say something like

let f x y z:int = (x = y) && (y = z)

so that it would be restricted to ints. (It frequently helped me to 
untangle cryptic error messages that ML produced, AND to document
my intent as I wrote code). I can still 
trick it into doing that, by something like

let f = function
  | (x,y,z) -> (x==y) && (y == z)
  | (a,b,_) -> (a-b) = 0;;

which will turn out to never invoke the second case, but still
restrict the 
type. But surely this is not more readable/maintainable code...(Yes, I
know
it has a slightly different signature, but I didn't have the heart to 
work around that just now). 

Thanks again for the informative answers. 

-John Hughes

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