[MLton] HOL's Moscow ML implementation, and pushing MLton to
Fri, 8 Apr 2005 13:39:25 -0700
> Let me rewrite the above as..
> > Basically, I think the problem comes down to figuring out a way to
> > represent all of the types known at compile time using an *unboxed*
> > representation, to embed these into a universal *boxed* typed, and to
> > figure out how to make the *polymorphic function* always use the
> > right representation of a type so that there are no coercions.
> See the below for a pretty good solution....
The solution in this paper applied to the current problem requires
changing the representation of the host types. I was hoping to avoid
this, as it obviates some of MLton's benefits (the approach in the
paper is part of the reason why SML/NJ is so much slower than MLton).
In any case, we already knew we could solve the problem by changing
the host types, i.e. by sticking the universal type in the host world
as I described in an earlier mail. Shao's paper shows how to use some
representations of the universal type other than the standard "fully
boxed" naive one. But, as far as I understand, it doesn't show how to
leave the host types fully unboxed with an open-ended interpreter as
we want. Although perhaps its reference to type passing as being at
the other end of the spectrum from coercion is a hint that type
passing might work.