7.1  General.

“No man really becomes a fool
  until he stops asking questions.”
Charles Proteus Steinmetz

7.1.1  How does Mythryl relate to SML/NJ?

Mythryl is a fork of the SML/NJ codebase.

The critical difference between Mythryl and SML/NJ is:

The goals of the two projects are in often in direct opposition — for example, incorporating untried bleeding-edge ideas is the raison d’etre of a research compiler, but is most unwelcome in a production compiler — so maintaining two separate projects helps keep keep everyone happy.

7.1.2  Why haven’t you implemented features X, Y and Z? Are you a lazy bum or what?

Bringing Mythryl this far this quickly cost me a lot of seven-day weeks and sixteen-hour days falling asleep at the keyboard and waking up to find a screenfull of ’j’s from where my finger was resting on the keyboard. (I have pictures of that!) I would love to have implemented X, Y and Z as well, but there are only so many hours in a year. Maybe you can help!

7.1.3  There’s no way to have default function arguments in f key1 => val1, key2 => val2

This is true. If you need argument defaulting, the best available approximation is to pass a list of appropriate sumtype values:

    f [ KEY1 val1, KEY2 val2 ];

The function called can then do a little list processing to collect values supplied and provide default values for those not supplied.

For what it is worth, the current Mythryl codebase as distributed contains over half a million lines of code, and the above mechanism appears seldom if ever; to date, at least, working Mythryl programmers do not seem to have felt much need for this.

7.1.4  Why is only 32-bit intel32 Linux supported?

Because for the moment that is what I’m familiar with, and it is more than enough to keep me busy.

There is always a strategic choice to be made between on the one hand maximum cross-platform portability and on the other hand maximum functionality on a single platform. The SML/NJ distribution leans toward maximum portability, which necessarily means being somewhat mediocre on each individual platform. With Mythryl I am more interested in offering excellent support for Linux (and more generally Posix) systems than in offering maximum portability.

The SML/NJ distribution from which Mythryl is derived is supported on Macs and Windows machines. I know nothing about either environment, so it would be presumptuous of me to attempt support for them, but I would be happy to work with anyone wanting to support Mythryl ports to those platforms.

I am sure I have during Mythryl development unintentionally introduced various breakages into support for those platforms, so there would be a significant initial effort required to revive those ports.

Supporting AMD64/Intel64 under Linux would definitely be nice, primarily because it would solve the intel32 register starvation problem. Shortage of registers is a critical performance problem for SML/NJ and Mythryl on 32-bit intel32. For example one study found that using integer programming to do register allocation in SML/NJ yielded a fifteen percent performance boost on 32-bit intel32 but nothing on the Alpha, PWRPC32 and Sparc architectures, which have more generous register allotments. (In the compiler optimization world fifteen percent is huge; typical overall improvements are one percent or less.)

Unfortunately, 32-bit constants and assumptions appear to be widely scattered through the Mythryl C runtime and compiler generation logic, so implementing support for AMD64/Intel64 will likely require a substantial initial clean-up effort.

7.1.5  Why is there no concurrent programming support?

Mythryl supports fate::callcc out of the box, which may be used to implement basic concurrency. src/app/makelib/concurrency/makelib-thread-boss.pkg provides a simple example of doing so.

The stackless design used by SML/NJ and Mythryl makes callcc extremely efficient; callcc is in essence just as fast as a normal function call. One study found SML/NJ callcc to be 47X faster than on the second-fastest system tested.

The SML world de facto standard concurrent programming solution is John H Reppy’s CML package, documented in his book Concurrent Programming in ML. (In the Ocaml world Jocaml is a more recent effort.)

This package is present in the Mythryl distribution under the directory src/lib/thread-kit. However Mythryl development to date has undoubtedly introduced unintentional breakage. I hope to revive and support this infrastructure within a year or so.

When writing CML Reppy was forced to write an almost complete replacement for the standard I/O libraries, which were not designed with concurrency in mind. Having to maintain and learn two complete sets of I/O libraries is obnoxious, so I intend to merge them as part of reviving this facility. This will however take significant effort.

Anyone impatient to have this facility available is encouraged to take on this project! :-)

7.1.6  Why is the Universe expanding?

To make room for additional stupidity.

Comments and suggestions to: