packages (was Re: [MLton] syntax error for "_address")

John Reppy
Thu, 3 Nov 2005 20:56:44 -0600

On Nov 3, 2005, at 7:57 PM, Stephen Weeks wrote:

>> I think that this is a fine philosophy (in fact, it is the one that I
>> follow for Moby), but the fact that mlton is a whole program compiler
>> means that I have no way to use the underlying system tools to  
>> package
>> SML libraries.
> I don't understand what the problem is.  There is the (obvious) fact
> that MLton needs the whole (SML) program in order to compile, but do
> you mean something else?  Why doesn't packaging SML libraries as
> source work?

Because there isn't a single logical entity that represented the  
At best, I'll need an mlb file and an include file for the application's
makefile.  Of course, if we get into a sharing situation, the include
file approach will break.

>> I think that CABAL is a tool that is supposed to support a common
>> package build specification across multiple compiler/OS
>> combinations.  What I think is attractive about the Haskell system
>> is that they recognize that it is not good enough to just think
>> about libraries composed of Haskell code.  Instead, they are
>> tackling the important situation of libraries comprised of both
>> Haskell and C code.
> Yes this is important, but I think it is a bad idea for Haskell or ML
> people to provide a new solution to the problem.  The point being that
> people in the C world and other worlds much larger than ours already
> have the problem of dealing with code from multiple languages,
> multiple compilers, multiple OS'es, etc.  They already have solutions.
> We're just one special case.  We need to provide enough features to
> fit within their solutions, but trying to get them to replace their
> solution with ours won't work.

Are there good examples of general-purpose multi-lingual packaging
mechanisms out there?  I'm not suggesting that one needs a tool to
replace make/autoconf/..., but rather a mechanism that supports the
notion of a multilingual package.

BTW, mlton violates this philosophy already; the "-target-*-opt"  
flags are
redundant with mechanisms already provided by make, etc.

	- John