I see AFS every day. When we moved into our current house, my daughter, whose initials are AFS, got hold of a Sharpie and proceeded to initial every surface in the house she could get to until my wife found her and curtailed her exhuberant tagging. I still (12 years later) find “AFS” scrawled in places I didn't know she had so tagged. And we haven't had the heart to remove them all anyway.
I used it a lot at Chicago in the early '90s, then never again. I always liked the idea, but Jesus Haploid Christ was it ever a PITA to set up (I'm looking at YOU, Kerberos.)
This is great, I've always liked SML. It has a lot of what I like about Haskell without breaking my brain, and it seems like it could be a good option for a pragmatic systems development language when used with MLton. I even toyed with the idea of developing an IDE plugin for it but was put off by the difficulty of parsing it.
Good luck guys! MLWorks had quite a reputation at the beginning of the century, and both ML & OCaml have then been already acclaimed as industrial strength functional languages.
Indeed, LispWorks was Harlequin's first actual product, paid for itself over many years and still does today in the hands of several of the original developers who acquired it after Harlequin went bust. The next product was ScriptWorks (a PostScript RIP), which became the company's cash cow and lives on as the Harlequin RIP from Global Graphics http://harlequinrip.com/ . That paid for the boss's pet projects, including MLWorks (which became a product in the mid 90s) and DylanWorks (which never quite did at Harlequin, but was carried on by ex-Harlequin people who set up Functional Objects, and survives today as OpenDylan). The other main thing to come out of Harlequin is Xanalys, who took on the various Lisp-based analytical projects (and ended up holding the MLWorks sources).
This is the second time that we have acquired our old projects from the heirs of Harlequin and open-sourced them: the first was the Memory Pool System http://www.ravenbrook.com/project/mps
Let's get it working again and see. On the original target platforms (SPARC/Solaris, and then MIPS/Irix) it was quicker than that era's SML/NJ on our favourite benchmark (recompiling the whole of MLWorks itself), by about 25% I think. When we first did the x86 port the performance was not so good (the lack of usable registers was a problem for a design that had originally been focussed on RISC architectures), but I think that had improved by the late 90s (I stopped work on the project by about 1996). O'CaML didn't really exist then.
It will be a challenge to beat SML/NJ if the implementation has not progressed much since then, much less MLton. Since the 90s, SML/NJ has gotten a new backend, garbage collector, and has gone through a significant amount of performance tuning for the massive changes that happened to machines (e.g., more than 4MB of RAM, multi-level caches, etc.). Further, MLton is still 2-10x faster than SML/NJ, especially on programs that make heavy use of mutation (ref cells and arrays).
That said, I think it's still awesome to ressurect this project for folks to play around with on modern hardware! It appears to have some of the full development environment experience that none of the rest of us in the ML community have put into our products.
The implementation has not progressed at all since 1999, when Harlequin folded. It doesn't do defunctorization, so probably can't compete with MLton on performance (but it does have an IDE including a REPL, unlike MLton). It's much closer to the Definition than SML/NJ (of course): once we have the compiler running again I'll be interested to use it on the MLton corner cases. And certainly the SML/NJ garbage collector was occasionally a subject of light-hearted mockery among MLWorkers. But as I say, I don't expect x86 performance to be all that great.
Certainly! SML/NJ was a research platform first and high-performance/implementation second.
Defunctorization helps, but from talking with Matthew Fluet, most of the perf comes from the combination of monomorphization and whole-program compilation. You get to avoid all the hackery involved with trying to mix essential inlining (e.g., map, foldl) with separate compilation and the somewhat unpredictable performance that results when a user accidentally writes their own map function but puts it in a separate source file without magical incantations for the inliner.
Also, we're working to get the rights for the definition back from MIT press so we can both push out a free PDF version and update the bugs. There are several corner cases that Harper, Tofte, and MacQueen consider mistakes in the '97 version of the definition, but haven't really taken the time to push out an updated definition, after the ML2000 effort went nowhere. Follow up with me offline (contact info in my profile) if you're morbidly curious.
I'm sure we'll be in touch. I suggest you join the mailing list, then you'll be able to track our progress (and you'll be the first to know once we have a working compiler).
Do give my regards to John Reppy, who I haven't seen for about 15 years. As I recall, he was the author of the "new" GC in SML/NJ (in the mid 90s), which was a distinct improvement on the original semi-space collector.
It would be excellent to have the Definition available online. MLWorks originated with a contract to develop a very strict implementation of the Definition, and we were quite proud of being truly Standard ML.
