Misc...

[Anoq of the Sun]

Stephen Weeks wrote:
> 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
> 
> is not.
> 
> 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.

Yes - I also just got this from Matthias Blume of the SML/NJ team:

Matthias Blume wrote:
> Correct me if I am wrong, but IMO the above should be translated into
> 
>   val rec Option = fn x => x
> 
> which _is_ permitted to override identifier status.  The Definition
> (page 24, bottom) makes this explicitly clear, giving the following
> example of a legal program:
> 
>   datatype t = f; val rec f = fn x => x;
> 
> So I'd venture to say that despite what Martin might say, SML/NJ and MLton
> have it right while the kit has it wrong here.

...

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

I'm going for a C-backend - basically because the deadline will be
tight and I know many of the issues of porting the C-backend quite well
by now I think :)

Also, I will need to bootstrap MLton itself for MacOS this time,
since nobody seem to know about crosscompiling Linux->Mac.
So I think the way to do it is to compile MLton itself to
C with a MacOS runtime and basislib, and then compile that
C file natively on Mac with gcc.


Cheers
-- 
http://www.HardcoreProcessing.com