<div dir="auto"><div>Thanks for writing this up!<div dir="auto"><br></div><div dir="auto">> <span style="color:rgb(51,51,51);font-size:14px;text-align:justify;background-color:rgb(255,255,255)">Note: should </span><code style="margin:0px;padding:1px;border:1px solid rgb(204,204,204);font-size:12px;line-height:inherit;font-family:monospace,sans-serif;vertical-align:baseline;background:rgb(246,246,246);color:rgb(51,51,51);text-align:justify">template-haskell</code><span style="color:rgb(51,51,51);font-size:14px;text-align:justify;background-color:rgb(255,255,255)"> be merged into </span><code style="margin:0px;padding:1px;border:1px solid rgb(204,204,204);font-size:12px;line-height:inherit;font-family:monospace,sans-serif;vertical-align:baseline;background:rgb(246,246,246);color:rgb(51,51,51);text-align:justify">base</code><span style="color:rgb(51,51,51);font-size:14px;text-align:justify;background-color:rgb(255,255,255)"> to make dependencies simpler?</span></div><div dir="auto"><br></div><br>I think the answer is "no" because it has non-base dependencies. We could vendor all of these like we do for the containers and filepath dependencies ATM, but I'm not sure if it's worth it. </div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Teo</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Wed, 7 Aug 2024, 16:27 Sylvain Henry, <<a href="mailto:sylvain@haskus.fr">sylvain@haskus.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div>
<p>Hi Simon,</p>
<p>As this came up again during the GHC call yesterday, I've written
some notes to explain the issues and the current status (as I
understand them):
<a href="https://hsyl20.fr/posts/2024-08-07-about-ghcs-stability.html" target="_blank" rel="noreferrer">https://hsyl20.fr/posts/2024-08-07-about-ghcs-stability.html</a></p>
<p>I hope that helps. Happy to get some feedback about this by other
people involved in the process.</p>
<p>Sylvain<br>
</p>
<p><br>
</p>
<div>On 20/10/2023 10:00, Simon Peyton Jones
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail_default" style="font-family:tahoma,sans-serif">
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.
</div>
</blockquote>
<div><br>
</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default">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. <br>
</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default"><br>
</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail_default" style="font-family:tahoma,sans-serif">Let's say that</div>
</blockquote>
<div class="gmail_default" style="font-family:tahoma,sans-serif">
<blockquote>
<ul>
<li>An old library mylib (which uses TH) depends on
base-4.7.</li>
<li>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>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>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`.)<br>
</div>
</blockquote>
<div>
<blockquote>
<blockquote>
<ul>
<li>That produces compiled object files, such as,
mylib:M.o. </li>
<li>To run TH we need to link them with the running
binary</li>
<li>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>
</blockquote>
<div>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>
</blockquote>
<div>(End of quote)</div>
<div><br>
</div>
<div>What am I missing?</div>
<div><br>
</div>
<div>Simon<br>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, 20 Oct 2023 at 08:57,
Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank" rel="noreferrer">arnaud.spiwack@tweag.io</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>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.<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, 19 Oct 2023 at
13:47, Oleg Grenrus <<a href="mailto:oleg.grenrus@iki.fi" target="_blank" rel="noreferrer">oleg.grenrus@iki.fi</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">For
what it worth, `template-haskell` itself depends on a
`base`. So if <br>
`base` if different base is used, different
`template-haskell` is to be <br>
used.<br>
<br>
In my opinion is not *too unfair* to require that if you
actually splice <br>
in (i.e. the code not only provides template-haskell
combinators to <br>
create/modify splices) then you must have base and
template-haskell <br>
versions aligned with host GHC used versions.<br>
<br>
The same restriction is GHC plugins, isn't it, except
`template-haskell` <br>
is replaced with `ghc`?<br>
<br>
- Oleg<br>
<br>
On 17.10.2023 18.54, Adam Gundry wrote:<br>
> Hi Simon,<br>
><br>
> Thanks for starting this discussion, it would be good
to see progress <br>
> in this direction. As it happens I was discussing
this question with <br>
> Ben and Matt over dinner last night, and
unfortunately they explained <br>
> to me that it is more difficult than I naively hoped,
even once <br>
> wired-in and known-key things are moved to
ghc-internal.<br>
><br>
> The difficulty is that, as a normal Haskell library,
ghc itself will <br>
> be 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 <br>
> a different version of base. This is rather like the
situation with TH <br>
> and 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 noreferrer" target="_blank">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 <br>
>> with base-4.10, or L's dependency bounds have not
yet been adjusted <br>
>> to allow 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 <br>
>> knows the precise place where (say) the type Int
is declared, and <br>
>> it'll get 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 <br>
>> mean that a newer GHC could compile old libraries
against their old <br>
>> 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 <br>
>> there would still be fantastic.)<br>
>><br>
>> Simon<br>
><br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank" rel="noreferrer">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote>
</div>
<br clear="all">
<br>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">Arnaud Spiwack<br>
Director, Research at <a href="https://moduscreate.com" rel="noopener noreferrer noreferrer" target="_blank">https://moduscreate.com</a>
and <a href="https://tweag.io" rel="noopener noreferrer noreferrer" target="_blank">https://tweag.io</a>.</div>
</div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank" rel="noreferrer">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
ghc-devs mailing list
<a href="mailto:ghc-devs@haskell.org" target="_blank" rel="noreferrer">ghc-devs@haskell.org</a>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank" rel="noreferrer">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank" rel="noreferrer">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div></div>