Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Ray tracer update
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Daniel C. Wang  
View profile  
 More options Jun 13 2005, 10:54 pm
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
>>>OCaml's compilers.

>>It might help compiler developers if you would describe the problems
>>in more detail.

> 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
> Mlton-specific):

> 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. :)

> 4. I currently prefer separate "+" and "+." (but I like OCaml's overloaded
> 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 "+".

You can define your own set of +. constants and define the appropriate
infix operators if you like that style.

> 5. I miss "for" loops. Although these can be implemented in the style of
> 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.

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.

> As well as the problems listed in Appel's critique of SML.

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