[MLton] Porting MLton... C99?

[Wesley W. Terpstra]

On Thu, Dec 09, 2004 at 07:11:35PM -0800, Stephen Weeks wrote:
> > All those printf("%08x", (uint)ptr); lines scattered everywhere are also a
> > problem. The best way to do this is to change it to printf("%08lx",
> > (ulong)z), no matter what type z is. When using uintX_t you have no idea
> > what that corresponds to in a format string so upgrading to the largest
> > portable formatted type is the best approach.
> 
> I agree with the principle.  But wouldn't using long long be better
> than long?

In theory...

But then printf needs to support it, which C99 does certainly require.
However, since we already use gcc with weird libcs (cygwin+mingw) and 
printf is implemented there, this is problematic. All libcs definitely
have %ld and %lx though.

Complicating matters is that C99 and SUSv2 conflict on some format strings
and I can never remember which, so I am always a bit leary of them.

I just doubled checked; fesetround + fpclassify exist under mingw libc.

> You might want to wait a day or two before starting

Ok. I will wait.
I have a lot of SML projects on the go, so no loss of time for me. =)

> 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 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 am not sure if having a 2 byte value makes sense. If MLton can pack 21 
or 24bits into strings in a nice way, I think the UCS2 is not needed.

I recall you mentioning in some commit message or comment somewhere that at
some point int31 will allow optimization of datatypes with two cases. This
is why I am asking if the limit of 21 bits is useful. My (still) C-oriented
brain doesn't really understand how representation optimizations can be
interoperable, but I know you compiler guys have your tricks. ;)

> Also, one thing I should confirm with you before you start making
> substantial runtime modifications.  MLton is currently released under
> the GPL.  Because MLton-generated executables are linked with the
> runtime, this means that they are infected with the GPL. 

Ack!
Actually, I didn't know that.

> We've been meaning to change this for some time (over a year), but haven't
> gotten to it.  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.
The end-goal of all this stuff I've been trying to bring to SML is an
application I am not convinced the GPL would adaquately protect. So, I am
definitely in favour of choice for application writers, namely me. ;)

I presume we're just talking about the runtime and basis library here?

> I just wanted to make sure you're OK with the less restrictive license
> vis-a-vis your contributions.  Sorry for not bringing this up sooner
> -- we plan to clean up the whole licensing situation in the next
> couple months, and get stuff up on the wiki explaining the situation.

Sure, you can consider all my contributions to MLton to have my copyright
assigned directly to you.

-- 
Wesley W. Terpstra