iserv doesn't solve issues with GHC plugins (e.g. type-checker plugins)?
As far as I understand, if there is a library with a type-checker
plugin, then that library is forced to use whatever dependencies `ghc`
library is using? I guess that is the fair restriction: such libraries
wouldn't be able to use non-bundled `base`
On 18.10.2023 5.30, Moritz Angermann wrote:
Something I haven’t gotten around to but only preliminary experiments
with is dynamically built iserv binaries.
Using -fexternal-interpreter can decouple the symbols the interpreter
sees and those the compiler sees (They can even be of different
architectures). iserv could be linked against the base the project
wants to use, whereas GHC itself could use a different base. I’m not
sure this covers everything, but it covers at least the case where we
don’t need to load two different packages into the same process.
Wrt to TH, I’m a bit behind on reading all the prior work to solve
this, but conceptually I still believe template-haskell itself should
not expose the internal ast, but only a combinator API to it.
Regarding DSO’s: let’s please not make the existence of DSO a hard
dependency. There are platforms for which we don’t have DSO
capabilities, and where we are forced to use the in-memory loader and
linker.
On Wed, 18 Oct 2023 at 4:17 AM, Simon Peyton Jones
<simon.peytonjo...@gmail.com> wrote:
(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
_______________________________________________
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
