<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>I think it is making progress. It's not just an engineering
      milestone but also messaging. Right now a huge issue that every
      Haskeller faces is new GHCs having new major versions of base. If
      we make clear that "it's not base's fault, it's Template Haskell's
      fault", then we will have an easier time coordinating people and
      eventually fundraising to get issued fixed with Template Haskell.</p>
    John
    <p></p>
    <div class="moz-cite-prefix">On 10/20/23 03:56, Arnaud Spiwack
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAGwnsnmz++aOvtC7fMNeAZprqpBH4ehrkv+St-Y-Wuf=u79Z5A@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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"
            moz-do-not-send="true" class="moz-txt-link-freetext">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" 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 <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"
            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 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" target="_blank"
            moz-do-not-send="true" class="moz-txt-link-freetext">https://moduscreate.com</a>
          and <a href="https://tweag.io" rel="noopener noreferrer"
            target="_blank" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://tweag.io</a>.</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>