[Haskell-cafe] Re: Non-technical Haskell question

[Robert Dockins]

Ketil Malde wrote:
> John Goerzen <jgoerzen at complete.org> writes:
> 
> 
>>>sensibly share libraries between apps.  Anyway, disc is cheap.
> 
> 
>>Memory not so much, though.  One advantage of having something in .so
>>form is that every instance of every application that uses it shares the
>>same in-memory image of the code.
> 
> 
> Well, a 5 Mbyte [1] overhead isn't really that much, IMHO.  You'd need to
> run a lot of (different; if they're the same, the text will be shared)
> applications to get any measurable benefit.  Eventually, it would be
> nice to have dynamic linkage, but I can see why it isn't a priority.
> 
> -kzm
> 
> [1] On my Linux system, the overhead seems to be less than 2
> Mbyte. 5 Mb is the figure used by the OP.

If we assume that Haskell programs are a) uncommon and b) the top of a 
solution stack (ie, not the OS, not the GUI toolkit, not the network 
stack) then this reasoning is sound, and we don't really need dynamic 
linking.  IF, on the other hand, you imageine Haskell wideing its 
borders and moving into other nitches, the value of dynamic linking 
becomes apparent.

The problem, of course, is that Haskell likes to tightly bind with the 
libraries it uses (inlineing across modules and other optimizations). 
So imaging if the "package" unit was a barrier to those kinds of 
optimizations.  Then, no knowledge of the internals of the package are 
needed by importing modules, and "sufficently" compatable pacakges could 
be drop in replacements, .so or .dll style.

I suppose I am suggesting that we consider the "package" as a unit which 
has a stable ABI.  Is this possible/easy to do?  Could we then implement 
dynamic linking w/ packages?