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

John Goerzen jgoerzen at complete.org
Mon Dec 6 12:29:13 EST 2004


On 2004-12-06, Robert Dockins <robdockins at fastmail.fm> wrote:
>> 
>> [1] On my Linux system, the overhead seems to be less than 2
>> Mbyte. 5 Mb is the figure used by the OP.

One other problem with that is that 5MB is a LOT on a device such as my
Zaurus.  I have an OCaml development environment on this PDA, as well as
a Python one, but I think that ghc is going to be out of the question.

> 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.

That is an excellent point.  Who would use an ls or cp that requires
10MB of RAM, especially on embedded devices?

> 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?

It seems that what we need is a way to control this cross-module
optimization.  I for one think that the performance benefit we see from
that is more than offset by the inconvenience.  If it were at least made
an option, then a lot of other options would become available to us,
too.

-- John



More information about the Haskell-Cafe mailing list