packages (was Re: [MLton] syntax error for "_address")
John Reppy
jhr@cs.uchicago.edu
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
library.
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