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.
No one has yet answered my naive question (from 3 days ago) asking why
Template Haskell stops base being reinstallable. I'll quote it here
for completeness.
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 that 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".
(End of quote)
What am I missing?
Simon
On Fri, 20 Oct 2023 at 08:57, Arnaud Spiwack <arnaud.spiw...@tweag.io>
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.gren...@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@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@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
