Newsgroups: comp.lang.functional
From: "Daniel C. Wang" <danwan...@gmail.com>
Date: Mon, 13 Jun 2005 19:54:52 -0700
Local: Mon, Jun 13 2005 10:54 pm
Subject: Re: Ray tracer update
Jon Harrop wrote: {stuff deleted} >>>My main gripe is the unfriendliness of the compilers compared to I think this is a fair and common gripe. However, the SML match compiler >>>OCaml's compilers. >>It might help compiler developers if you would describe the problems > Yes, I shall try to make a compendium of example programs and errors. > In the mean time I can list some points about SML itself (not > 1. Not having capitalised constructors worries me, although I've never had a 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 SML does have "val rec" > only really serves to heighten the "activation barrier" for newbies. 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 Well this is not exactly fair, since there's only one OCaml system > 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). around. :) > 4. I currently prefer separate "+" and "+." (but I like OCaml's overloaded You can define your own set of +. constants and define the appropriate > printf), although this might change as I grow more accustomed to SML. > However, I have been bitten by different inferred types from SML/NJ and > Mlton due to overloaded "+". infix operators if you like that style. > 5. I miss "for" loops. Although these can be implemented in the style of MLton supports single precision float types. Single precision float > SML/NJ, they seem to result in awful indentation. (Update: I'll read the > latest post on this) > 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. 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, There's been quite a bit of work in this area. MLTon's FFI is pretty > 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. 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. > As well as the problems listed in Appel's critique of SML. I've finally found my self in a position that makes me have to program > Of course, SML is still one of the best languages that I've come across and 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! > I'll have a go at translating the examples from my OCaml book when I find
> the time. You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| ||||||||||||||