<div dir="auto"><div>> What am I missing?</div><div dir="auto"><br></div><div dir="auto"><br><div data-smartmail="gmail_signature" dir="auto">Hi Ben, </div><div data-smartmail="gmail_signature" dir="auto"><br></div><div data-smartmail="gmail_signature" dir="auto">I'm talking about dynamic-too support, which I am still working on getting back in Windows. </div><div data-smartmail="gmail_signature" dir="auto"><br></div><div data-smartmail="gmail_signature" dir="auto">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.</div><div data-smartmail="gmail_signature" dir="auto"><br></div><div data-smartmail="gmail_signature" dir="auto">So I wanted to see if the implementation cost isn't high if we could do the library split now.</div><div data-smartmail="gmail_signature" dir="auto"><br></div><div data-smartmail="gmail_signature" dir="auto">But if it is then no problem, I'll find a work around. </div><div data-smartmail="gmail_signature" dir="auto"><br></div><div data-smartmail="gmail_signature" dir="auto">Thanks, </div><div data-smartmail="gmail_signature" dir="auto">Tamar </div><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Sat, Mar 25, 2023, 16:54 Ben Gamari <<a href="mailto:ben@smart-cactus.org">ben@smart-cactus.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Phyx <<a href="mailto:lonetiger@gmail.com" target="_blank" rel="noreferrer">lonetiger@gmail.com</a>> writes:<br>
<br>
>> I highly doubt that this split will have any measurable overhead.<br>
>> Reexporting a definition defined in one module from another module via<br>
>> an export list does not produce any code at all; importing such a<br>
>> declaration is equivalent to importing the definition from the defining<br>
>> module.<br>
><br>
> Ah right, I can see how that's true at the Haskell level but..<br>
><br>
>> If for some reason we can't in some cases directly reexport then we<br>
>> would likely rather have a some very trivial bindings that GHC would be<br>
>> quite eager to inline.<br>
><br>
> Sure, I can see how you'd inline based on the haskell contract, I can't see<br>
> how you avoid the compile time overhead when compiling the library. If you<br>
> have a haskell library<br>
><br>
<br>
> module Test (Control.Monad.when, Control.Applicative.many) where<br>
><br>
> import Control.Monad(when)<br>
> import Control.Applicative(many)<br>
><br>
> compiling it:<br>
><br>
>  ghc test.hs<br>
> [1 of 1] Compiling Test             ( test.hs, test.o )<br>
><br>
> which still contains the closure for the library.<br>
<br>
I'm a bit lost. When I compile this module I get an object which<br>
contains no references to `when` or `many`. The only references to these<br>
two symbols should be in the interface file. What am I missing?<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br>
</blockquote></div></div></div>