[MLton] Porting MLton... C99?
Wesley W. Terpstra
Fri, 10 Dec 2004 04:59:50 +0100
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?
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.
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