nick_barnes

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.

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.

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.