Ketil Malde wrote:
John Goerzen <[EMAIL PROTECTED]> 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?
_______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
