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

[Matthew Fluet]

>>> 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'm trying to understand John's point of view.  Are you equally critical 
of the situation in mono-lingual but multi-library software composition? 
For example, in a straight C project which makes use of other C libaries, 
I still need to do two things: 1) use #include "gmp.h" in the appropriate 
source files, and 2) use -L... -lgmp in the appropriate linker invocation 
(and, possibly, 3) use -I...  in the appropriate compiler invocations).

I guess MacOS's -framework flag avoids the tedium of -I... -L... -l..., 
but you're still responsible for knowing what libraries contribute to your 
software when you build it.  Note, this remains the case through all the 
transitive dependencies.

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

How so?