“No man really becomes a fool
until he stops asking questions.”
— Charles Proteus Steinmetz
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.
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!
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.
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.
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! :-)
To make room for additional stupidity.