<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>I think the problem with different stability in different parts
      of base is that it makes it very difficult for package maintainers
      to get an accurate set of bounds. If you write<tt> base >= 4.8
        && < 5</tt><tt> </tt>you may later need to revise
      the bounds, and if you write <tt>base >= 4.8 && <
        4.12 </tt>you will likely have bounds be too strict (which may
      not be revised for every package version...).<br>
      <br>
      I had the impression that splitting <tt>base</tt> would be done
      using backpack, so that you could provide alternate <tt>base</tt>
      implementations for e.g. GHCJS. <br>
      <br>
      There's a 4 year-old trac ticket <a moz-do-not-send="true"
        href="https://ghc.haskell.org/trac/ghc/ticket/10266">here</a>
      which has some other stuff. There, it talks about user-provided <tt>base</tt>
      implementations as the advantage rather than versioning. I think
      this approach is likely to provide the biggest improvements
      without breaking anything. <br>
    </p>
    <div class="moz-cite-prefix">On 10/30/18 12:37 PM, Sven Panne wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CANBN=mtp-VxiRFgsE51Yr7+Jjh2wBbemmpmj=u3hBTf50zK8SQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div class="gmail_quote">
          <div dir="ltr">Am Di., 30. Okt. 2018 um 16:32 Uhr schrieb
            Daniel Cartwright <<a href="mailto:chessai1996@gmail.com"
              moz-do-not-send="true">chessai1996@gmail.com</a>>:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div dir="auto">DOA seems kinda harsh at this point.</div>
          </blockquote>
          <div><br>
          </div>
          <div>I think "DOA" is the right description for every proposal
            touching the foundations of a language ecosystem in an
            incompatible way *unless* there are very, very good reasons
            to break things. And even then, you should better have a
            good migration story. Python 3 anybody?</div>
          <div> </div>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div dir="auto"> If base just re-exports the stuff, that
              makes sense, but wouldn't we want to move it out
              eventually?</div>
          </blockquote>
          <div><br>
          </div>
          <div>Hmmm, what problem exactly should be solved by splitting
            base? Has this been written down somewhere? Edward mentioned
            different stability in different parts of base, which is
            certainly true, but do we have concrete convincing examples
            of problems caused by that? Does a migration story exist? I
            just want to remind everybody about the trouble and effort
            involved in pushing the AMP and FTP through the ecosystem,
            which are probably peanuts compared to a reorganization of
            base...</div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Libraries mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Libraries@haskell.org">Libraries@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a>
</pre>
    </blockquote>
  </body>
</html>