Mon, 16 Jul 2001 10:06:34 -0700
> 1) Earlier I reported a bug for the MLKit compiler -
> but now Martin Elsman <email@example.com>
> (whom you might know already?) told me that the bug
> is in my code and SML/NJ and MLton :)
> According to The Definition, it should not be possible
> to define the following function:
> fun Option x = x
> It should (according to The Definition) be translated
> into something like:
> val Option = fn x => x
> And Option is an exception constructor bound in the SML Basis Library.
> However the function compiles fine with SML/NJ and MLton. OK - maybe
> you can argue that it's not a bug in MLton, since MLton does not really
> typecheck - but I thought you might want to know :)
We are definitely interested in hearing about such bugs, since eventually we
want to have a real front end. However, in this case, what you say is
incorrect. There must be some confusion in your communication with Martin,
since the version of the MLKit that I have (3.9.1) handles this correctly, as
does SML/NJ and MLton. That is,
fun Option x = x
is legal, while
val Option = fn x => x
According to Figure 17, page 57, of the definition, "fun Option x = x" expands
to "val rec Option = fn x => x". Note the presenc of "rec". Thus, according to
rule 26, page 24, this overrides the definition of the Option exception.
> 2) I'm now involved in a new game-project that I will
> probably be doing for a company. And it has to run on Mac OS...
> So I believe that I will be porting MLton to MacOS soon
> (if all goes well :)
> Do you know of anything I might have to be aware of when
> porting? Such as the big-endianness of the PowerPC processor
> might affect the way MLton works etc.
First, do you mean to port the C backend or create a new native one? And yes,
endianness matters, alignment matters, word size matters, ... We've never done
a port, so I'm sure we'll be surprised in lots of places. But all of those
problems should be fixable.
> 4) I'm really glad to see that you have links for my homepage :)
> But actually - CeX3D Converter does not convert images - it
> converts 3D objects... :)
Sorry about that. We've put a fix up.