Hi Ben,
I'm talking about dynamic-too support, which I am still working on getting back in Windows.
In the grand scheme of things it doesn't matter much, as it doesn't work today. But a forwarder library in that scenario still will have a compile time cost in the current scheme for how dynamic-too works on Windows.
So I wanted to see if the implementation cost isn't high if we could do the library split now.
But if it is then no problem, I'll find a work around.
Thanks,
Tamar
Phyx <lonetiger@gmail.com> writes:
>> I highly doubt that this split will have any measurable overhead.
>> Reexporting a definition defined in one module from another module via
>> an export list does not produce any code at all; importing such a
>> declaration is equivalent to importing the definition from the defining
>> module.
>
> Ah right, I can see how that's true at the Haskell level but..
>
>> If for some reason we can't in some cases directly reexport then we
>> would likely rather have a some very trivial bindings that GHC would be
>> quite eager to inline.
>
> Sure, I can see how you'd inline based on the haskell contract, I can't see
> how you avoid the compile time overhead when compiling the library. If you
> have a haskell library
>
> module Test (Control.Monad.when, Control.Applicative.many) where
>
> import Control.Monad(when)
> import Control.Applicative(many)
>
> compiling it:
>
> ghc test.hs
> [1 of 1] Compiling Test ( test.hs, test.o )
>
> which still contains the closure for the library.
I'm a bit lost. When I compile this module I get an object which
contains no references to `when` or `many`. The only references to these
two symbols should be in the interface file. What am I missing?
Cheers,
- Ben