Daniel C. Wang wrote:
> Jon Harrop wrote:
> {stuff deleted}
>> 1. Not having capitalised constructors worries me, although I've never
>> had a problem (probably because I capitalise them anyway). Could a
>> compiler flag be added to warn of non-capitalised constructors? That
>> would essentially solve that problem.

> I think this is a fair and common gripe. However, the SML match compiler
> is good at spotting errors when you confusing constructors. I find it
> unfortunate that the OCaml pattern match semantics aren't as strong as
> SML. In particular if I'm not mistaken it's impossible for Ocaml's match
> compiler to catch redundant or non-exhaustive matches.

>> 2. I prefer explicit "rec", not implicit as in SML's "fun". I think this
>> only really serves to heighten the "activation barrier" for newbies.

> SML does have "val rec"

> val rec fib = (fn 0 => 0 | 1 => 0 | n => fib(n-1) + fib(n-2))

> not the most pretty I agree.

>> 3. No standard way to compile a Standard ML program - MLton- and
>> SML-compiled programs must be different. I was also surprised to find no
>> mach_eps in SML/NJ (perhaps more surprisingly, pre 1.4 Java also lacks
>> this).

> Well this is not exactly fair, since there's only one OCaml system
> around. :)

>> 6. I think a single precision float type for storage in general data
>> structures is a good idea (this makes the x86 C++ version of my ray
>> tracer twice as fast with only trivial changes). There may already be one
>> in SML that I've missed. OCaml only has big arrays.

> MLton supports single precision float types. Single precision float
> types are an "optional" part of the Standard Basis. (I have a gripe that
> the Standard Basis has too many optional parts...)

>> 7. After all the time and effort spent making SML itself very robust,
>> comparatively little effort seems to have been placed on making it
>> interface safely with non-SML libraries. I can see why, historically, but
>> it is a significant thorn in the idea of teaching SML as a general
>> purpose programming language on an undergrad course.

> There's been quite a bit of work in this area. MLTon's FFI is pretty
> straightforward. The new FFI of SML/NJ is pretty sophisticated. Other
> can chime in... what I know about the OCaml FFI makes me feel like it's
> not soo much better.

>> Of course, SML is still one of the best languages that I've come across
>> and I'm hugely impressed with its definition, implementations and
>> practical application. So my overall feeling for SML is extremely
>> positive, which might not come across in these criticisms.

> I've finally found my self in a position that makes me have to program
> in C++. I dearly miss SML! SML has it's warts.. but most of the warts
> are erring on the side of clean simple semantics. Some times the clean
> and simple thing is a bit verbose and at times clunky. C++ seems to err
> on the side of making things very concise, but god knows what going on!