Reinstallable - base

[Oleg Grenrus]

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
>