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

[Stephen Weeks]

> I have a library of SML code that I want to use in multiple
> applications.  It depends on C libraries and it uses "_export" to
> generate C code.  I can provide both a Makefile and mlb file for the
> library, but how will these connect to the application build
> process?  How am I going to pass requirements for C libraries,
> etc. up to the application's build process? 

How would you do this if your library was written in C instead of SML?
(I do not mean this sarcastically)

Our philosophy is to integrate with existing tools and build processes
as much as possible.  Producing our own replacement for make or
existing packaging systems would take a lot of effort, would likely
produce worse results (than the better ones anyway), and would make
tools harder for people to use than the ones they know.  So, Matthew's
answer to your question is the right one: MLBs live within whatever
existing mechanism (e.g. make) you have for expressing requirements,
handling platform dependencies, and building applications.

MLBs exist to solve a problem that makes sense solely in the context
of SML (namely, namespace control at the module level) and solve the
problem in the spirit of SML, with a clean static and dynamic
semantics.  Other components necessarily sit on top of MLBs to make
real-world things happen, but to complicate MLBs to handle such issues
would lead to a worse overall system with fewer clearly understood
components.

> The GHC package system provides a nice mechanism for this problem;
> you might want to check it out.

I am passingly familiar with Haskell's CABAL and am not at all
convinced that its package description files are a good solution to
the problem.