[Haskell-cafe] Re: Non-technical Haskell question
robdockins at fastmail.fm
Mon Dec 6 12:08:34 EST 2004
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  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.
>  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
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?
More information about the Haskell-Cafe