Wait… so SML# is not actually a Standard ML implementation that compiles programs to run on top of the .NET runtime (like C#, F# and the discontinued J# and Spec#), but instead it’s just a normal compiler (of an extended SML) with an LLVM backend?
That’s a bit misleading, to say the least :) Since I have no interest in .NET, I had completely dismissed it just because of the # suffix…
I was going to protest that SML# “was first”, but I believe C# did indeed come before SML#. The # comes from the polymorphic record accessor syntax.
The earliest stuff on SML# I can find is from 2005.
If you haven’t taken a look at SML# it’s more than just another implementation. They’ve really innovated with the language, for example, with builtin SQL expressions (sort of like LINQ).
They only just translated the manual to English in the last few years. The implementation seems to be picking up steam/going (more) mainstream if anything.
My impression is that there was an effort in 2021 and early 2022, with the book, an earnest github presence, and lots of English translations. And yet it seems that things have quieted down considerably since then. Take a look at the issues/PRs in github – most haven’t been addressed in a year or more.
Contrast this with something like polyml’s github page. Issues/PRs are at least acknowledged on a regular basis, and commits coming in with some regularity.
As I mentioned at the bottom of the post: if I were to dive into a “modernized” standard ML system today, knowing what I know, I’d be looking at Mizuki Arata’s (SML# contributor in his own right) LunarML. It looks much more vigorous, just going by coding/blogging activity alone.
it’s possible, of course, to have a layer of SML# code that serves as the ‘parser’ layer, and then create truly pure models from this ‘parser’ layer, but practically speaking no one is going to go to these lengths in the name of elegance or flexibility.
Isn’t that indicative that this 1:1 mapping approach is not really a problem in practice? And if it became a problem, we could always just create pure model types and migrate over to those, thanks to the confident refactoring capabilities of statically typed programming?
in contrast with OS-level threads that regular SML implementations use, SML# offers drop-in support for a “green-thread” system called MassiveThreads. These are much cheaper to initialize and run, enabling finer-grained parallelism and better utilization of CPU resources.
This is also what OCaml’s Eio is doing with its Fibers. In practice, OCaml is the industrial-strength ML that everyone is looking for…
This really adds up, and works against the ‘practical’ bent of the language. Fast compilation, and therefore developer feedback, is why Turbo Pascal was so popular back in the day :)
Just fyi, OCaml compile speeds are similar to Go :-)
Re: 1) I’m on the fence. I think it’s not a problem on small projects, where there is conceptual alignment about how things are modeled, i.e: the team has a shared understanding of the theory of the program. But when you’re on a huge team and the schema starts creaking, and different people have different ideas how things should be stored, the 1:1 correspondence is no longer such a boon. Denormalization, relational restrictions, indexes, various performance tweaks, raw queries, etc… a system that maps 1:1 starts getting in the way. In my experience of course.
Re: 2) I know Ocaml is the industrial-strength ML, but I’m simply engaging in anti-work, anti-industrial, wholesome fun programming here. I just want to rekindle my love for the subject and learn something new.
Wait… so SML# is not actually a Standard ML implementation that compiles programs to run on top of the .NET runtime (like C#, F# and the discontinued J# and Spec#), but instead it’s just a normal compiler (of an extended SML) with an LLVM backend?
That’s a bit misleading, to say the least :) Since I have no interest in .NET, I had completely dismissed it just because of the
#suffix…And conversely, people who are actually interested in running SML on .NET would be disappointed once they read more :-)
I was going to protest that SML# “was first”, but I believe C# did indeed come before SML#. The
#comes from the polymorphic record accessor syntax. The earliest stuff on SML# I can find is from 2005.Apparently, SML# dates back to 1993, so you were right the first time.
That would be SML.NET, a whole-program optimizing compiler, waiting to be resuscitated.
When I saw it, at first I was like “SML#? isn’t that just … F#?”
F# was derived from OCaml, though. SML and OCaml are quite a bit different.
If you haven’t taken a look at SML# it’s more than just another implementation. They’ve really innovated with the language, for example, with builtin SQL expressions (sort of like LINQ).
Chapters 12 and 22 of their manual cover this: https://smlsharp.github.io/en/documents/4.0.0/manual.pdf.
Yeah, it’s a real shame SML# has gotten so little attention, after so many engineer-years have been put into its development.
They only just translated the manual to English in the last few years. The implementation seems to be picking up steam/going (more) mainstream if anything.
My impression is that there was an effort in 2021 and early 2022, with the book, an earnest github presence, and lots of English translations. And yet it seems that things have quieted down considerably since then. Take a look at the issues/PRs in github – most haven’t been addressed in a year or more.
Contrast this with something like polyml’s github page. Issues/PRs are at least acknowledged on a regular basis, and commits coming in with some regularity.
As I mentioned at the bottom of the post: if I were to dive into a “modernized” standard ML system today, knowing what I know, I’d be looking at Mizuki Arata’s (SML# contributor in his own right) LunarML. It looks much more vigorous, just going by coding/blogging activity alone.
Isn’t that indicative that this 1:1 mapping approach is not really a problem in practice? And if it became a problem, we could always just create pure model types and migrate over to those, thanks to the confident refactoring capabilities of statically typed programming?
This is also what OCaml’s Eio is doing with its Fibers. In practice, OCaml is the industrial-strength ML that everyone is looking for…
Just fyi, OCaml compile speeds are similar to Go :-)
Re: 1) I’m on the fence. I think it’s not a problem on small projects, where there is conceptual alignment about how things are modeled, i.e: the team has a shared understanding of the theory of the program. But when you’re on a huge team and the schema starts creaking, and different people have different ideas how things should be stored, the 1:1 correspondence is no longer such a boon. Denormalization, relational restrictions, indexes, various performance tweaks, raw queries, etc… a system that maps 1:1 starts getting in the way. In my experience of course.
Re: 2) I know Ocaml is the industrial-strength ML, but I’m simply engaging in anti-work, anti-industrial, wholesome fun programming here. I just want to rekindle my love for the subject and learn something new.
Re 3) I know, I know, see above ;)