> Is there any reason to use SML instead of OCaml in 2024?
* Many compilers and transpilers available. Don't like LunarML? Maybe try Poly/ML. Or MLton. Or MLKit. Or SML/NJ. Etc. All of the above are pretty much complete and production quality, and there are quite a few more.
* The language has a formal specification which means there's a document formally specifying what all the constructs in the language should do. In contrast, if you wanted to build your own OCaml compiler/transpiler/interpreter, you'd basically have to follow whatever the main OCaml implementation does, which changes from one version to the next, so you'd always be playing catch-up.
* The formal specification hasn't changed since 1997. This means that once written, your SML code should work the same forever. You no longer have to worry about your programs (or their dependencies) breaking when you upgrade to a new version of OCaml.
* Compared to OCaml, your single-threaded programs will usually run faster if you compile them with MLton, mostly due to whole-program optimization / monomorphization and unboxed native integers, reals and arrays.
* Some SML implementations have interesting extensions, which you can use (at the cost of being tied to that implementation). For example, MLKit supports memory regions (i.e. more efficient memory management in some cases). SML# (which is not related to .NET) supports seamless integration with SQL and other interesting features. Some implementations support multi-threading natively and/or different forms of parallelism. Most of them also support some form of FFI to interface with C or other languages.
* SML programs are easier to port to CakeML than any other language, since CakeML is mostly an SML subset. CakeML not only allows you to formally verify that your program is correct (or that it has certain desirable properties), but it also has a compiler that is formally proven to be correct, so your compiled CakeML programs are (mostly) guaranteed to be free of miscompilation bugs as well.
Multicore programming that isn’t covered in stickers about being bleeding edge and not fully integrated with the rest of stdlib(s?). Since the 90s. :)
And a minor point: operator arguments (as well as curried arguments) are evaluated left-to-right, not right-to-left like in OCaml.
someplaceguy|1 year ago
* Many compilers and transpilers available. Don't like LunarML? Maybe try Poly/ML. Or MLton. Or MLKit. Or SML/NJ. Etc. All of the above are pretty much complete and production quality, and there are quite a few more.
* The language has a formal specification which means there's a document formally specifying what all the constructs in the language should do. In contrast, if you wanted to build your own OCaml compiler/transpiler/interpreter, you'd basically have to follow whatever the main OCaml implementation does, which changes from one version to the next, so you'd always be playing catch-up.
* The formal specification hasn't changed since 1997. This means that once written, your SML code should work the same forever. You no longer have to worry about your programs (or their dependencies) breaking when you upgrade to a new version of OCaml.
* Compared to OCaml, your single-threaded programs will usually run faster if you compile them with MLton, mostly due to whole-program optimization / monomorphization and unboxed native integers, reals and arrays.
* Some SML implementations have interesting extensions, which you can use (at the cost of being tied to that implementation). For example, MLKit supports memory regions (i.e. more efficient memory management in some cases). SML# (which is not related to .NET) supports seamless integration with SQL and other interesting features. Some implementations support multi-threading natively and/or different forms of parallelism. Most of them also support some form of FFI to interface with C or other languages.
* SML programs are easier to port to CakeML than any other language, since CakeML is mostly an SML subset. CakeML not only allows you to formally verify that your program is correct (or that it has certain desirable properties), but it also has a compiler that is formally proven to be correct, so your compiled CakeML programs are (mostly) guaranteed to be free of miscompilation bugs as well.
SassyBird|1 year ago
And a minor point: operator arguments (as well as curried arguments) are evaluated left-to-right, not right-to-left like in OCaml.