(Meta-question: on reflection, would this discussion perhaps be better on a ticket? But where? GHC's repo? Or HF's?)
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. I'm not understanding the difficulty yet. Let's say that - An old library mylib (which uses TH) depends on base-4.7. - 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. - 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. 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`. - That produces compiled object files, such as, mylib:M.o. - To run TH we need to link them with the running binary - 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 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". What am I missing? Simon On Tue, 17 Oct 2023 at 16:54, Adam Gundry <a...@well-typed.com> wrote: > Hi Simon, > > Thanks for starting this discussion, it would be good to see progress in > this direction. As it happens I was discussing this question with Ben > and Matt over dinner last night, and unfortunately they explained to me > that it is more difficult than I naively hoped, even once wired-in and > known-key things are moved to ghc-internal. > > The difficulty is that, as a normal Haskell library, ghc itself will be > compiled against a particular version 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. This is rather like the situation with TH and > cross-compilers. > > Adam > > > > On 17/10/2023 11:08, Simon Peyton Jones wrote: > > Dear GHC devs > > > > Given the now-agreed split between ghc-internal and base > > <https://github.com/haskellfoundation/tech-proposals/pull/51>, what > > stands in the way of a "reinstallable base"? > > > > Specifically, suppose that > > > > * GHC 9.8 comes out with base-4.9 > > * The CLC decides to make some change to `base`, so we get base-4.10 > > * Then GHC 9.10 comes out with base-4.10 > > > > I think we'd all like it if someone could use GHC 9.10 to compile a > > library L that depends on base-4.9 and either L doesn't work at all with > > base-4.10, or L's dependency bounds have not yet been adjusted to allow > > base-4.10. > > > > We'd like to have a version of `base`, say `base-4.9.1` that has the > > exact same API as `base-4.9` but works with GHC 9.10. > > > > Today, GHC 9.10 comes with a specific version of base, /and you can't > > change it/. The original reason for that was, I recall, that GHC knows > > the precise place where (say) the type Int is declared, and it'll get > > very confused if that data type definition moves around. > > > > But now we have `ghc-internal`, all these "things that GHC magically > > knows" are in `ghc-internal`, not `base`. > > > > *Hence my question: what (now) stops us making `base` behave like any > > other library*? That would be a big step forward, because it would mean > > that a newer GHC could compile old libraries against their old > dependencies. > > > > (Some changes would still be difficult. If, for example, we removed > > Monad and replaced it with classes Mo1 and Mo2, it might be hard to > > simulate the old `base` with a shim. But getting 99% of the way there > > would still be fantastic.) > > > > Simon > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > Registered in England & Wales, OC335890 > 27 Old Gloucester Street, London WC1N 3AX, England > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs