Reinstallable - base

[John Ericson]

I think it is making progress. It's not just an engineering milestone 
but also messaging. Right now a huge issue that every Haskeller faces is 
new GHCs having new major versions of base. If we make clear that "it's 
not base's fault, it's Template Haskell's fault", then we will have an 
easier time coordinating people and eventually fundraising to get issued 
fixed with Template Haskell.

John

On 10/20/23 03:56, Arnaud Spiwack wrote:
> A very large proportion of libraries, and virtually all end-user 
> applications, transitively depend on Template Haskell. Whether they 
> use Template Haskell directly or not. So if we're saying “base is 
> reinstallable, except when you have Template Haskell somewhere”, we're 
> effectively saying “base is not reinstallable”. Now, it could be a 
> good stepping-stone, from an engineering standpoint, but I don't think 
> we could deliver this and be satisfied that we've accomplished anything.
>
> On Thu, 19 Oct 2023 at 13:47, Oleg Grenrus <oleg.grenrus at iki.fi> wrote:
>
>     For what it worth, `template-haskell` itself depends on a `base`.
>     So if
>     `base` if different base is used, different `template-haskell` is
>     to be
>     used.
>
>     In my opinion is not *too unfair* to require that if you actually
>     splice
>     in (i.e. the code not only provides template-haskell combinators to
>     create/modify splices) then you must have base and template-haskell
>     versions aligned with host GHC used versions.
>
>     The same restriction is GHC plugins, isn't it, except
>     `template-haskell`
>     is replaced with `ghc`?
>
>     - Oleg
>
>     On 17.10.2023 18.54, Adam Gundry 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
>     >
>     _______________________________________________
>     ghc-devs mailing list
>     ghc-devs at haskell.org
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> -- 
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20231020/85c35234/attachment.html>