...> It seems fairly clear that StandardML is used by fewer ..., all practical implementations extend the "standard" with extra language features. SML/NJ... but SML/NJ cannot. Alice ML adds platform-independent persistence. And ..., all practical implementations extend the "standard" with features like incompatible FFIs.... compile platform independent applets using standard APIs for GUIs (GTK?), graphics ...
It seems fairly clear that StandardML 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.
Vesa Karvonen wrote: Torben Ægidius Mogensen <torbenm@app-4.diku.dk> wrote: And there is no standardized FFI that works for all SML imlementations. That's true. ML-NLFFI is currently supported by both SML/NJ and MLton. It would probably make sense to try and port it to a few ...
... Most of the libraries work with MLton, SML/NJ, Poly/ML, and MLKit. In the future, I will try porting ...done some preliminary work towards that), SML.NET, Moscow ML, and Alice ML (these are not in any sort of ... contributions are of course welcome! And there is no standardized FFI that works for all SML imlementations. That's true. ML-NLFFI is currently supported by both SML/NJ and ...
... <vesa.karvonen@cs.helsinki.fi> writes: I think that the biggest problem with SML today is lack of libraries. Or, at least, lack of well designed, easily obtainable, maintained, and documented libraries. 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
...... SML/NJ adds guarded and or-patterns ... 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 wrote: Jon Harrop <usenet@jdh30.plus.com> 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. AFAIK, there are already other people currently working on both a 64-bit backend for SML/NJ and OpenGL bindings (actually...
Jon Harrop <usenet@jdh30.plus.com> 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. 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 ...
Joachim Durchholz wrote: Jon Harrop schrieb: There are more implementations of the queens problem listed for SML than there are for OCaml according to Google: sml "queens problem": 314 ocaml "queens problem": 311 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....
Jon Harrop schrieb: There are more implementations of the queens problem listed for SML than there are for OCaml according to Google: sml "queens problem": 314 ocaml "queens problem": 311 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 ...
