Re: Buy-in for technical proposal 47 which affect GHC devs

What am I missing?

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 On Sat, Mar 25, 2023, 16:54 Ben Gamari wrote:

Phyx 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