<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">(Meta-question: on reflection,
would
this discussion perhaps be better on a ticket? But where? GHC's repo? Or HF's?)</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The difficulty is that, as a normal Haskell library, ghc itself will be compiled against a particular verson of base. Then when Template Haskell is used (with the internal interpreter), code will be dynamically loaded into a process that already has symbols for ghc's version of base, which means it is not safe for the code to depend on a different version of base.</blockquote></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I'm not understanding the difficulty yet.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Let's say that</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><ul><li>An old library mylib (which uses TH) depends on base-4.7.</li><li>A new GHC, say GHC 9.10, depends on a newer version of base-4.9, which in turn depends on ghc-internal-9.10.</li><li>At the same time, though, we release base-4.7.1, which depends on ghc-internal-9.10, and exposes the base-4.7 API.</li></ul><div>At this point we use ghc-9.10 to compile L, against base-4.7.1. (Note the the ghc-9.10 binary includes a compiled form of `base-4.9`.<br></div><div><ul><li>That produces compiled object files, such as, mylib:M.o. </li><li>To run TH we need to link them with the running binary</li><li>So we need to link the compiled `base-4.7.1` as well. No problem: it contains very little code; it is mostly a shim for ghc-internal-9.10</li></ul><div>So the only thing we need is the ability to have a single linked binary that includes (the compiled form for) two different versions/instantiations of `base`. I think that's already supported: each has a distinct "installed package id".</div><div><br></div><div>What am I missing?</div><div><br></div><div>Simon<br></div></div></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 17 Oct 2023 at 16:54, Adam Gundry <<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Simon,<br>
<br>
Thanks for starting this discussion, it would be good to see progress in <br>
this direction. As it happens I was discussing this question with Ben <br>
and Matt over dinner last night, and unfortunately they explained to me <br>
that it is more difficult than I naively hoped, even once wired-in and <br>
known-key things are moved to ghc-internal.<br>
<br>
The difficulty is that, as a normal Haskell library, ghc itself will be <br>
compiled against a particular version of base. Then when Template <br>
Haskell is used (with the internal interpreter), code will be <br>
dynamically loaded into a process that already has symbols for ghc's <br>
version of base, which means it is not safe for the code to depend on a <br>
different version of base. This is rather like the situation with TH and <br>
cross-compilers.<br>
<br>
Adam<br>
<br>
<br>
<br>
On 17/10/2023 11:08, Simon Peyton Jones wrote:<br>
> Dear GHC devs<br>
> <br>
> Given the now-agreed split between ghc-internal and base <br>
> <<a href="https://github.com/haskellfoundation/tech-proposals/pull/51" rel="noreferrer" target="_blank">https://github.com/haskellfoundation/tech-proposals/pull/51</a>>, what <br>
> stands in the way of a "reinstallable base"?<br>
> <br>
> Specifically, suppose that<br>
> <br>
> * GHC 9.8 comes out with base-4.9<br>
> * The CLC decides to make some change to `base`, so we get base-4.10<br>
> * Then GHC 9.10 comes out with base-4.10<br>
> <br>
> I think we'd all like it if someone could use GHC 9.10 to compile a <br>
> library L that depends on base-4.9 and either L doesn't work at all with <br>
> base-4.10, or L's dependency bounds have not yet been adjusted to allow <br>
> base-4.10.<br>
> <br>
> We'd like to have a version of `base`, say `base-4.9.1` that has the <br>
> exact same API as `base-4.9` but works with GHC 9.10.<br>
> <br>
> Today, GHC 9.10 comes with a specific version of base, /and you can't <br>
> change it/. The original reason for that was, I recall, that GHC knows <br>
> the precise place where (say) the type Int is declared, and it'll get <br>
> very confused if that data type definition moves around.<br>
> <br>
> But now we have `ghc-internal`, all these "things that GHC magically <br>
> knows" are in `ghc-internal`, not `base`.<br>
> <br>
> *Hence my question: what (now) stops us making `base` behave like any <br>
> other library*? That would be a big step forward, because it would mean <br>
> that a newer GHC could compile old libraries against their old dependencies.<br>
> <br>
> (Some changes would still be difficult. If, for example, we removed <br>
> Monad and replaced it with classes Mo1 and Mo2, it might be hard to <br>
> simulate the old `base` with a shim. But getting 99% of the way there <br>
> would still be fantastic.)<br>
> <br>
> Simon<br>
<br>
-- <br>
Adam Gundry, Haskell Consultant<br>
Well-Typed LLP, <a href="https://www.well-typed.com/" rel="noreferrer" target="_blank">https://www.well-typed.com/</a><br>
<br>
Registered in England & Wales, OC335890<br>
27 Old Gloucester Street, London WC1N 3AX, England<br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>