Fw: Re: Re: Re: [MLton] self-compiling failed

Matthew Fluet matthew.fluet at gmail.com
Thu May 20 11:13:48 PDT 2010


On Wed, May 19, 2010 at 10:46 PM, Baojian Hua <huabj at mail.ustc.edu.cn> wrote:
>> -----Original E-mail-----
>> From: "Matthew Fluet" <matthew.fluet at gmail.com>
>> Sent Time: 2010-5-19 21:51:36
>> To: "Baojian Hua" <huabj at mail.ustc.edu.cn>
>> Cc: mlton <mlton at mlton.org>
>> Subject: Re: Re: [MLton] self-compiling failed
>>
>> It is enabled under a SML/NJ build of MLton.  From the root of the
>> mlton source tree, a "make smlnj-mlton" will build a SML/NJ heap image
>> and copy it to build/lib.  The build/bin/mlton script will prefer a
>> MLton build of MLton over a SML/NJ build of MLton, so be sure to
>> remove build/lib/mlton-compile.  Because SML/NJ's cutoff recompilation
>> is faster than MLton's whole program compilation, this is generally
>> the way I work when debugging something like an SSA IL optimization
>> pass.
>
> Thanks. But in building with smlnj, the source "ssa/poly-hash.fun" won't
> compile. A close look at the code reveals that changing the line 305 to
>
> fun fini (hexp: Dexp.t): Dexp.t = hexp
>
> can shut up the compiler.
>
> Does this mean a bug in smlnj?

It is a known issue with SML/NJ using an overly restrictive context
for type inference.  But, to keep the sources compatible with SML/NJ,
we usually include sufficient type constraints.  I guess no one has
needed to build with SML/NJ in a while, but I committed a fix
(slightly different than your constraint, but accomplishes the same).



More information about the MLton mailing list