[MLton] Porting MLton... C99?

Stephen Weeks MLton@mlton.org
Thu, 9 Dec 2004 20:17:17 -0800

> > You might want to wait a day or two before starting
> Ok. I will wait.

It went faster than planned.  I just checked it in.  Still no
front-end support, but I should be pretty much done touching gc.c.

> > as I am in the middle of tweaking the compiler and runtime
> > to support UCS2 and UCS4 string constants.
> You didn't say anything about whether or not Word21 would be a good thing.

I have longer email planned once I get the coding done, but in short,
yes.  MLton does packing optimizations on tuples/records, so Word21
could take less space than Word32.  MLton won't do anything special
for a Word21 (or Word24) array.  I agree with Henry's points that it's
not likely to be worth it.

> I originally wanted UCS2 and UCS4 as well, but in the interests of not
> confusing users and keeping things simple, I've been convinced by others
> that having just WideChar = all of Unicode probably is best and simplest.
> Unicode 4.0 is the range 0x01-0x10FFFF, which is under 21 bits.
> The main motivation (for me) behind UCS2 was that it is much more compact.

I agree that UCS2 is worth it for the factor of 2 savings.  Let's do

> I recall you mentioning in some commit message or comment somewhere
> that at some point int31 will allow optimization of datatypes with
> two cases.

Yes, this has been done for a few months now.  So that, e.g. 

	datatype t = A of Int31.int | B of Int31.int

is stored in a single 32-bit word.

> My (still) C-oriented brain doesn't really understand how
> representation optimizations can be interoperable

It's not interoperable via the FFI.  Only types that directly map to C
types are.  And MLton is whole-program, so as long as it's consistent,
it can represent most types however it would like.

> > The plan is to go to a less restrictive license that allows
> > people to use MLton without having to GPL their executable.
> This would be a good thing, imo.
> I presume we're just talking about the runtime and basis library
> here?

Yes, that's the only place where relaxating the license is essential.
Although we may relax it further ... still undecided.