Magnus Therning wrote:
On Fri, Oct 3, 2008 at 12:59 PM, Simon Marlow <[EMAIL PROTECTED]> wrote:
Magnus Therning wrote:
On Wed, Oct 1, 2008 at 6:03 PM, Simon Marlow <[EMAIL PROTECTED]>
wrote:
[..]
Dynamic linking doesn't solve all the problems, we still have the problem
that GHC does a lot of cross-module inlining, regardless of whether
dynamic
linking is used. However, I really would like to have a way to have
complete control over what is exposed across a package boundary. We need
this not just for licensing reasons, but also for making a dynamic
library
with a fixed ABI, so it can be upgraded later.
I have a really hard time following this. Are you seriously saying
that GHC is inlining code from modules _and_ link dynamically at the
same time. That seems like a remarkably strange thing to do, or maybe
I'm just missing something.
That's exactly what would happen, if we shipped dynamic linking support with
GHC as it stands. It's just a linking mechanism, an alternative to static
linking, and has no impact on the amount or nature of inter-module
optimisation that GHC does.
Ah, now I understand. The object for GHC would be to reduce the
system-wide use of memory rather than substitutability of DLLs then,
right?
Why would it be interesting to have sharable objects without substitutability?
It'll make our binary distributions a lot smaller for one thing. Also, the
on-disk size of binaries will be a lot smaller - this is something you
notice if you run a GHC test suite, for example.
Also, the GHCi binary contains the base package, but loads up another
complete copy when it starts up. And if you load up the GHC package inside
GHCi, then you have two complete copies of GHC in memory. Dynamic linking
fixes all this.
Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
