[MLton] Re: exene example

[Matthew Fluet]

> Here is the non working copy of eXene and a MLton with all apropriate changes 
> to the basis and CML needed to build exene.  The main change to MLton was 
> adding a packword16 functor (also the reason why i cannot compile with keep 
> exception history true), its located where packword32 is.

The duplication of the Basis Library implementation is the reason that 
-const 'Exn.keepHistory true'  causes an internal type error.  The 
definition of the "Exn.extra" type (used to carry the exception history) 
is "type extra = CallStack.t option".  However, the implementation of 
exception history in one Basis Library is incompatible with the 
implementation in the other Basis Library, as the "option" types are 
different.  The reason it manifests as an internal type error, rather than 
a front-end type error is that there is some additional implementation of 
exceptions done by the compiler, which uses the "Exn.extra" type from one 
Basis Library everywhere, even for exception history manipulated by the 
other Basis Library.


To be honest, I'm surprised that there weren't other insurmountable 
obstacles to duplicating the Basis Library.  I suspect that because CML 
uses a rather pure subset of the Basis Library (it's trying to avoid using 
shared state in the presence of concurrency), it isn't too bad.

Unfortunately, it isn't immediately clear to me why the duplication would 
lead to an uncaught interrupted system call exception.  There is the fact 
that exceptions are generative, but the restart of a system call is done 
based on its return code and errno, so no exceptions are involved at this 
level.  Checking whether or not the program is in a critical section is 
done by consulting shared state in the runtime (rather than the Basis 
Library), so that shouldn't be the issue.