It seems fairly clear that Standard ML is used by fewer functional
programmers than O'Caml, Erlang and Haskell.
I can understand this for Erlang, with an industrial push behind it.
Not for the other two. Ideas about this, no matter how far-out, are
welcomed.

"David B. Benson" eecs.wsu.edu> writes:

One idea: the SML vs Ocaml split is basically about practicality
(Ocaml) vs theoretical purity (SML). But the theoretical purists are
mostly using Haskell, leaving SML squeezed in the middle.

David B. Benson wrote:

I have many ideas for this, of course:

. SML left a lot to be desired as a language and, consequently, all
practical implementations extend the "standard" with extra language
features. SML/NJ adds guarded and or-patterns but MLton does not. MLton
generalizes ad-hoc polymorphism further but SML/NJ cannot. Alice ML adds
platform-independent persistence. And so on.

. SML was insufficient as a tool and, consequently, all practical
implementations extend the "standard" with features like incompatible FFIs.
Writing reliable and up-to-date OpenGL bindings is extremely important and
extremely hard. SML/NJ has its own FFI and its own bindings to some of
OpenGL with few examples. SML# has its own FFI and its own bindings to some
of OpenGL with few examples and so on...

Jon Harrop schrieb:

If you infer the number of implementation from a Google search that
gives you a difference of less than 1%%, then that's just careless reasoning.
(No wonder people say you're jumping to conclusions.)

(Largely agreeing with other stuff, except for those performance-related
areas - not because I have better numbers, but because I think your
focus on raytracing numerics is too narrow to allow any statements about
language performance in general.)

Joachim Durchholz wrote:

Given that I was blatantly being facetious, perhaps I wasn't the one who
jumped to the wrong conclusion? :-)

On Nov 11, 1:34 am, Jon Harrop jdh30.plus.com> wrote:

Guarded? I know about or-patterns, but not guarded ones. Are you
sure? If so, an example I could try?

I found all six replys (so far) helpful.

I'll go on to add that despite a start-up flurry of interest in
'sucessor ML', nothing further seems to have occurred. Does this mean
we all are eventually going to be using O'Caml or Haskell?

Vesa Karvonen writes:

I think you hit the nail there. The SML basis library is
well-designed, but rather limited. And there is no standardized FFI
that works for all SML imlementations.

Torben

Torben Ægidius Mogensen wrote:

[...]

I'm working on writing some minor extensions on top of the basis
library

http://mlton.org/cgi-bin/viewsvn.cgi/mltonlib/trunk/com/ssh/extended-basis/unsta.../

and I've also written a few other libraries. Most of the libraries
work with MLton, SML/NJ, Poly/ML, and MLKit. In the future, I will
try porting to other implementations such as SML# (I've already done
some preliminary work towards that), SML.NET, Moscow ML, and Alice ML
(these are not in any sort of order of preference).

User feedback and contributions are of course welcome!

Vesa Karvonen wrote:

I think you would get more useful work done if you focused on SML/NJ and
MLton and forgot about the other compilers. A 64-bit backend for SML/NJ and
OpenGL 2 bindings would be a good start.

Jon Harrop jdh30.plus.com> wrote:
[...]

AFAIK, there are already other people currently working on both a
64-bit backend for SML/NJ and OpenGL bindings (actually, I've heard
that there are several OpenGL bindings for SML, but I haven't looked
at any of them in depth).

-Vesa Karvonen