[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
it.
> 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.