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

[Brian Hurt <bhurt@spnz.org>]

On Thu, 24 Jun 2004, John Hughes wrote:

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

Let doesn't need them- there are a lot of other places where Ocaml could 
use disambiguation.  Basically, I'm a beleiver that if there is a 
shift-reduce conflict in the obvious implementation of the grammar, there 
is a problem the programmer is going to trip over.

One big one- I wish if was ended with an endif or similiar.  How many 
times have you accidentally coded something like:

if x > 3 then
    printf "x = %d\n" x;
    x - 3
else
    x + 1

This is especially common when, like in my example, you're dropping in 
debug print statements.  Unfortunately, the semicolon at the end of the 
printf statement also ends the if statement.

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

How would I make a list of one element of type int * int?

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

sqrt(2.);;

Mathematicians don't have a problem with dealing with an infinite number 
of decimal places.  Computers do.  You can hide some of the problems- at 
great cost in terms of performance and memory- but sooner or later you're 
going to deal with precision loss.

$ ocaml
        Objective Caml version 3.07

# 0.1 +. 0.1 +. 0.1 +. 0.1 +. 0.1 +. 0.1 +. 0.1 +. 0.1 +. 0.1 +. 0.1;;
- : float = 0.999999999999999889

Plus, all the comments I made about integers apply, and then some.  
Hardware based floating point is much faster than any software based 
floating point (even ignoring the infinities and nan problems).  Going to 
software base FP is easily 10x slower than hardware, possible (probably) 
more.  And doesn't really save you much of anything.

This is just pointing up, to me, why there is a difference between a 
teaching language and a production language.  As something looking at 
using Ocaml as a production language, I am opposed to even adding overflow 
detection on ints- in the few, minor places I need it, I'll either use 
larger integers, or I'll add in explicit checks myself.  But don't slow 
down even a little the vast majority of my integer operations.  This goes 
at least double for my floating point operations.

For a teaching language, I'd definately include integer overflow detection 
at the least, and would seriously consider making integers arbitrary 
precision.  I'd also strongly consider making floats software, but not so 
that I could increase precision, but so that I could decrease precision- 
numerical instability is a lot easier to demonstrate if you only have four 
digits of precision, and not 15.  But, then again, performance isn't a 
concern with a production language.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

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