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