Post by duke
i hears it used in practice somewhere... but alice definetely needs
updating to modern realities and closing bugs.
yes, could be worse... and, yes, it's interesting environment.
So what implementation of SML would you recommend?
as others already sayed, it depends on your needs.
i'm not expert ... but can remember some on all ML versions
(not CAML, it has somewhere different target audience).
...oh-o, seems i know many... seven!... implementations, beside alice...
looks like with ML you definetely NOT vendor-locked, like with gnat or
evergrow ghc! he-he...
0) so, alice... it's bytecoded implementation and purposely will be such
(for code migration). as such it somewhere slow (but has jit) and more or less
portable. as i remember, have some problems with oses which "not linux" (like xBSD).
base sml language in it is greatly extended with parallel and distributed features,
with constraint programming, etc. which is not so well-founded and narrow as in
smlsharp case. general and powerful, of course. but you not always need power,
sometimes predictability and reliability is preferred... having solution you
deny other solutions... and as sayed, standards (Standard ML 97) is good.
1) smlnj. the so named "standard implementation of ML". i use it some, it's average.
oriented to dynamic, explorating, interactive use. memory images can be stored to
file and runned on other computer with same runtime version (or can be packed
with runtime forming independent, somewhere big, executable),
but smlnj is not for binaries. it's big, elaborated, interactive environment.
memory consumption is moderate. generates native code in-memory (MLRISC backend)
and so has slower compiling time than mosml, has somewhere bigger memory
consumption also, but faster run times (on par with mlkit).
2) mlton. optimizing compiler. i say it "optimising whole picture, not small peepholes",
optimising-at-large. it do less optimisations-in-small than gcc, i think, but apply
optimisations-in-big more thoroughly (some peepholes rests unoptimized, sse not used
etc). supports parallelism (threads), as is polyml, but in somewhere different way.
resulting binaries is self-contained and relatively small (what not used is not included).
one BIG problem with it - it's a real memory and processor hog, and always will be.
it can easy eat gigabytes because of "whole-programness" and multiple passes
of optimisation transformations in memory. and because of that it sometimes can't
be used on old desktops or netbooks. i recommend you setup zswap in your linux for
this beast. peoples recommends use mlton for compiling release binaries only.
some game developers or crossdevelopers use it as wunderwaffe.
there is one possible trap in "use for final release only".
"whole-program"-ness somewhere changes semantic for some SML constructs
(like scope for definitions). this can be good (you get efficient functors for free!)
or bad. it depends... be warned.
3) polyml. compact interactive system. two files, easily distributed with application.
has parallelism. i think internally looks like smlnj (generate native code in-memory),
but smaller and simpler. moderate sequential performance, but people say it has
good parallel scalability. main application - polyml powers isabelle theorem prover.
i do not know if polyml GC is parallelized now (that somewhere limited speedup
on 4-6 in applications other than symbolic computations with small shared state),
but it is actively supported.
4) mlkit. simple native batch compiler (MLRISC-based codegenerator, as smlnj).
optimisator in this compiler is simple and gives moderate quality.
not so good in optimisation as mlton, but more predictable. has small runtime.
really great things in this compiler is:
region-based memory allocation (compiler optimise some work for gc,
make it possible to program realtime systems) and
separate module compilation (really good thing for incremental big project development).
try to use it together with mlton.
it's bad, bad that this compiler somewhere forgetted and leaved in shadows!
5) moscow ml. bytecode interpreter on old caml (wich was before ocaml) runtime.
fast compiles, slow runtimes (no jit). compact. have separate module compilation.
as i hear, have some problems with float numbers. some admins use it as scripting
language and for small web interfaces. in the past some use it for theorem provers.
small memory consumption is main goodie of this implementation.
6) hamlet. interpreter of full ml written in ml. useful in teaching and
experimenting with language, can be in one big sml file.
slow, of course. compile it with mlton.
7) smlsharp. interesting ml native-code x86 compiler. roots of project grows from
mlkit as i think (it not related with dotNet and c-sharp). so characteristics is also like
of mlkit. have good c interoperability. somewhere polished in fresh, release version.
hey, developers say it has parallelized gc now.
has ml language extended with some enterprise-y constructions like records and
such. and this extensions try to be formally verified and theoretically founded
(meanwhile, i personally do not like oop and inheritance, but managers like).
developed by japan government-founded project, they tries to get language for
usual commercial development, specially targeted at low maintenance costs
(like Ada was). i ask developers if it will have jvm codegen in future (for more
"enterpriseness"). they reply - "maybe". interesting project, i will look at it future...
resulting runtime performance grade from fast to slow:
1) mlton (on par with c or even faster)
2) mlkit, smlsharp, smlnj (1.5-2 times from mlton)
2.5) polyml (2-3 times).
(alice, i think, somewhere between poly and mosml)
3) mosml (5-10)
4) hamlet (you bet)