[MLton] MinGW + x86_64

[Wesley W. Terpstra]

On May 10, 2006, at 9:44 PM, Matthew Fluet wrote:
>> Error: ..\lib\mlton\basic\vector.sml 10.29.
>>  Variable type in structure disagrees with argument signature.
>>    variable: unfoldi
>>    structure: _ -> [ 'a t ]
>>    signature: _ -> [ 'a t  * 'b ]
>>
>> ... I am guessing this is due to a broken upgrade path? However, I  
>> don't have this problem on the MacOS build. I'm using mlton  
>> 20051109 on MacOS and MLton 20051202 on MinGW.
>
> Its a broken upgrade path on MinGW.  If you look at mlton/Makefile,  
> there is code to select stubs when compiling with an out of date  
> compiler. However, the stubs don't work with MinGW.

I read the comment and saw that it said 'fork' is unavailable. Ok,  
fine. So, I tried editing the lib/mlton-stubs/mlton.sml to pass  
spawn* through to the real MLton object  and re-enabled stubs.  
However, when the bootstrapped compiler runs, it exits immediately  
with a SysErr (it also is much smaller than it should be).

Shouldn't this approach be preferred to manually working around it on  
MinGW for each release? After all, disabling the upgrade path for  
something as minor as a missing fork() call (when we have viable  
alternatives) is a bit overkill.

> You could hand propagate the changes to basis-library/mlton/vector. 
> {sig,sml} into your 20051109 install.

I've done this and gotten further. (Though there were quite a few  
more files than two :-)

>> Also, Matthew, are you planning to fix/change the signedness issue  
>> for c-types.ml? Obviously, I could hack this, but it seems you  
>> have some larger vision about how the types are supposed to be  
>> inferred from the system.
>
> I do plan on fixing the signedness issue for the use of C-types in  
> the Basis Library, although it probably won't be this evening.

For now, on MinGW I just hacked my system header. The only type  
problem there was that C_INo_t (ino_t) is actually signed. A quick  
modification to /mingw/include/sys/types.h and MLton compiles further.

At this point, I get past type-checking all the libraries.
However, now I get a nice type mismatch problem when compiling mllex  
with the bootstrapped compiler.

It happily succeeds at parseAndElaborate, but fails in xmlSimplify/ 
TypeCheck after detecting that 'word16' != 'word32' giving a Type  
error: type mismatch. It then helpfully dumps the entire mllex XML  
IL. =D

Trying a smaller test program:
val () = print "Hello world\n"
also gives the same problem.

I would therefore hypothesize that there are two bugs..? One in the  
basis library related to the new type autodetection, where there is a  
type mismatch somewhere. The other, in the front-end which failed to  
detect this type error. I have no idea how to proceed... I'm quite  
surprised the front-end didn't tell me the location in the basis that  
causes the problem. Also, the IL dump doesn't say where in the IL the  
type error occurred, or I might be able to work my way backwards...

I've commited the c-types.sml which works on MinGW (with hacked  
C_INo_t). I think that's all you need to reproduce the compile error  
on linux, right?