[MLton] Re: exene example

Lukasz S Ziarek lziarek@cs.purdue.edu
Wed, 31 Aug 2005 17:59:58 -0500


Matthew Fluet wrote:

>
>> Type inference issues....
>>
>> For whatever reason we had many problems with infering option types 
>> in this exene build.
>
>
> I think many of your problems arise from an inappropriate use of .mlb 
> files.  For example, you have:
>
> portExene/eXene/examples/triangle/sources.mlb:
>
> local
>  /homes/lziarek/stabalize/code/mlton/basis-library/basis.mlb
>  /homes/lziarek/stabalize/code/mlton/basis-library/mlton.mlb
>  /homes/lziarek/stabalize/code/mlton/lib/cml/cml-lib/cml-lib.mlb
>  /homes/lziarek/stabalize/code/mlton/lib/cml/cml.mlb
>   ../../sources.mlb
> in
>   icon-bitmap.sml
>   mltonTri.sml
> end
>
> This will almost certainly cause problems, because cml/cml.mlb 
> (whether it is at /homes/lziarek/stabalize/code/mlton/lib/ or at 
> $(SML_LIB)) has:
>
> ann
>    "forceUsed"
> in
>    core-cml/core-cml.mlb
>    cml-lib/cml-lib.mlb
> end
>
> and cml/cml-lib/core-cml/core-cml.mlb has:
>
> ann
>    "sequenceNonUnit warn"
>    "nonexhaustiveMatch warn" "redundantMatch warn"
>    "warnUnused true"
> in
>    local
>       $(SML_LIB)/basis/basis.mlb
>       $(SML_LIB)/basis/mlton.mlb
> ...
>
>
> What is happening is that you are compiling two separate copies of the 
> Basis Library: one from 
> /homes/lziarek/stabalize/code/mlton/basis-library and one from 
> $(SML_LIB)/basis.  (Most likely $(SML_LIB) is set to 
> /usr/share/mlton/sml, but it might also be set to something like 
> /home/fluet/mlton/mlton.svn.HEAD/build/lib/sml if you are invoking a 
> local build.)
>
> This explains your "option" problem, because the "option" types 
> defined in the two copies of the Basis Library are different.  (In 
> particular, option is defined directly as "datatype 'a option = NONE | 
> SOME of 'a", and hence is generative.)
>
> I suspect that this is also the cause of some of your other problems, 
> but I'll investigate a little more.
>
>
> My suggestion, if you need to modify the Basis Library and CML 
> Library, would be to isolate your work in a directory:
>
> /homes/lziarek/stabalize/code/mlton.eXene
>
> with a full check-out of the MLton source tree.  Make your 
> modifications to the Basis Library and the CML Library in
>
> /homes/lziarek/stabalize/code/mlton.eXene/basis-library
> /homes/lziarek/stabalize/code/mlton.eXene/lib/cml-lib
>
> respectively.  Build MLton (i.e., make all) in your mlton.eXene 
> directory.
>
> Update your eXene port to use $(SML_LIB)/basis and $(SML_LIB)/cml-lib 
> instead of absolute paths.  When you want to compile and test an eXene 
> example, make sure that you invoke:
>   /homes/lziarek/stabalize/code/mlton.eXene/build/bin/mlton
> That will ensure that you are compiling with $(SML_LIB) pointing to 
> your modified libraries.
>
> If you need to make further modifications to the Basis Library or the 
> CML Library, you will need to do "make basis libraries" afterward to 
> propagate your changes to the build/lib/sml directory, which is where 
> $(SML_LIB) will be pointing.  That will be much quicker than "make all".

I did indeed also update the paths in the basis library and cml library 
mlbs so that everything would be consistant (though incorrectly).  
However, the error you found is still the cases, because the paths in 
the cml.mlb and core-cml.mlb pointed to
../../../build/lib/sml/basis/basis.mlb
../../../build/lib/sml/basis/mlton.mlb
which will be out of date without a make-basis correct? Hence the 
duplicate definitions of everything (the eXene paths pointed to 
mlton/basis-library/...).

Luke