<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
iserv doesn't solve issues with GHC plugins (e.g. type-checker
plugins)?<br>
<p>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`<br>
</p>
<br>
<div class="moz-cite-prefix">On 18.10.2023 5.30, Moritz Angermann
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAKfdd-yp7rjH74z1vvg0k63xetCj8iRn-hKGqnKJD9c0vKdmaw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">Something I haven’t gotten around to but only
preliminary experiments with is dynamically built iserv
binaries.</div>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto"><br>
</div>
<div dir="auto">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. </div>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto"><br>
</div>
<div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, 18 Oct 2023 at
4:17 AM, Simon Peyton Jones <<a
href="mailto:simon.peytonjones@gmail.com"
moz-do-not-send="true" class="moz-txt-link-freetext">simon.peytonjones@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
<div dir="ltr">
<div class="gmail_default"
style="font-family:tahoma,sans-serif">(Meta-question: on
reflection,
would this discussion perhaps be better on a ticket? But
where? GHC's repo? Or HF's?)</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif">
<blockquote class="gmail_quote" style="margin:0px 0px
0px
0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;font-family:tahoma,sans-serif;border-left-color:rgb(204,204,204)">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.</blockquote>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif">I'm not
understanding the difficulty yet.</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif">Let's say that</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif">
<ul style="font-family:tahoma,sans-serif">
<li style="font-family:tahoma,sans-serif">An old
library mylib (which uses TH) depends on base-4.7.</li>
<li style="font-family:tahoma,sans-serif">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.</li>
<li style="font-family:tahoma,sans-serif">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.</li>
</ul>
<div style="font-family:tahoma,sans-serif">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`.<br>
</div>
<div style="font-family:tahoma,sans-serif">
<ul style="font-family:tahoma,sans-serif">
<li style="font-family:tahoma,sans-serif">That
produces compiled object files, such as,
mylib:M.o. </li>
<li style="font-family:tahoma,sans-serif">To run TH
we need to link them with the running binary</li>
<li style="font-family:tahoma,sans-serif">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</li>
</ul>
<div style="font-family:tahoma,sans-serif">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".</div>
<div style="font-family:tahoma,sans-serif"><br>
</div>
<div style="font-family:tahoma,sans-serif">What am I
missing?</div>
</div>
</div>
</div>
<div dir="ltr">
<div class="gmail_default"
style="font-family:tahoma,sans-serif">
<div style="font-family:tahoma,sans-serif">
<div style="font-family:tahoma,sans-serif"><br>
</div>
<div style="font-family:tahoma,sans-serif">Simon<br>
</div>
</div>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, 17 Oct 2023 at
16:54, Adam Gundry <<a
href="mailto:adam@well-typed.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">adam@well-typed.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Hi
Simon,<br>
<br>
Thanks for starting this discussion, it would be good to
see progress in <br>
this direction. As it happens I was discussing this
question with Ben <br>
and Matt over dinner last night, and unfortunately they
explained to me <br>
that it is more difficult than I naively hoped, even
once wired-in and <br>
known-key things are moved to ghc-internal.<br>
<br>
The difficulty is that, as a normal Haskell library, ghc
itself will be <br>
compiled against a particular version of base. Then when
Template <br>
Haskell is used (with the internal interpreter), code
will be <br>
dynamically loaded into a process that already has
symbols for ghc's <br>
version of base, which means it is not safe for the code
to depend on a <br>
different version of base. This is rather like the
situation with TH and <br>
cross-compilers.<br>
<br>
Adam<br>
<br>
<br>
<br>
On 17/10/2023 11:08, Simon Peyton Jones wrote:<br>
> Dear GHC devs<br>
> <br>
> Given the now-agreed split between ghc-internal and
base <br>
> <<a
href="https://github.com/haskellfoundation/tech-proposals/pull/51"
rel="noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/haskellfoundation/tech-proposals/pull/51</a>>,
what <br>
> stands in the way of a "reinstallable base"?<br>
> <br>
> Specifically, suppose that<br>
> <br>
> * GHC 9.8 comes out with base-4.9<br>
> * The CLC decides to make some change to `base`,
so we get base-4.10<br>
> * Then GHC 9.10 comes out with base-4.10<br>
> <br>
> I think we'd all like it if someone could use GHC
9.10 to compile a <br>
> library L that depends on base-4.9 and either L
doesn't work at all with <br>
> base-4.10, or L's dependency bounds have not yet
been adjusted to allow <br>
> base-4.10.<br>
> <br>
> We'd like to have a version of `base`, say
`base-4.9.1` that has the <br>
> exact same API as `base-4.9` but works with GHC
9.10.<br>
> <br>
> Today, GHC 9.10 comes with a specific version of
base, /and you can't <br>
> change it/. The original reason for that was, I
recall, that GHC knows <br>
> the precise place where (say) the type Int is
declared, and it'll get <br>
> very confused if that data type definition moves
around.<br>
> <br>
> But now we have `ghc-internal`, all these "things
that GHC magically <br>
> knows" are in `ghc-internal`, not `base`.<br>
> <br>
> *Hence my question: what (now) stops us making
`base` behave like any <br>
> other library*? That would be a big step forward,
because it would mean <br>
> that a newer GHC could compile old libraries
against their old dependencies.<br>
> <br>
> (Some changes would still be difficult. If, for
example, we removed <br>
> Monad and replaced it with classes Mo1 and Mo2, it
might be hard to <br>
> simulate the old `base` with a shim. But getting
99% of the way there <br>
> would still be fantastic.)<br>
> <br>
> Simon<br>
<br>
-- <br>
Adam Gundry, Haskell Consultant<br>
Well-Typed LLP, <a href="https://www.well-typed.com/"
rel="noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://www.well-typed.com/</a><br>
<br>
Registered in England & Wales, OC335890<br>
27 Old Gloucester Street, London WC1N 3AX, England<br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">ghc-devs@haskell.org</a><br>
<a
href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs"
rel="noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote>
</div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">ghc-devs@haskell.org</a><br>
<a
href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
ghc-devs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a>
</pre>
</blockquote>
</body>
</html>