<div dir="ltr">We could have some sort of "base-base", the pared down core, and base, the existing core that provides all modules that it currently provides. This seems pretty essential for backwards compatibility if we don't want to break the world.<br><br>Since there would be conflicts between the modules provided by base and the modules provided by its component packages, projects would have to choose one (e.g. just use base) or the other (e.g. use the component packages a la carte), or use package imports... or somehow teach ghc that these modules are the same and it doesn't matter where they come from.<br><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">-- Dan Burton</div></div><br><input name="virtru-metadata" type="hidden" value="{"email-policy":{"state":"closed","expirationUnit":"days","disableCopyPaste":false,"disablePrint":false,"disableForwarding":false,"enableNoauth":false,"expires":false,"isManaged":false},"attachments":{},"compose-id":"9","compose-window":{"secure":false}}"><br><div class="gmail_quote" style=""><div dir="ltr">On Tue, Oct 30, 2018 at 11:32 AM Daniel Cartwright <<a href="mailto:chessai1996@gmail.com">chessai1996@gmail.com</a>> wrote:<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. If base just re-exports the stuff, that makes sense, but wouldn't we want to move it out eventually?<div dir="auto"><br></div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 30, 2018, 11:29 AM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto">Yeah</div></div><div dir="auto"><br></div><div dir="auto">The point ofnsplit base as an idea or goal is to make base simply reexport stuff.  Not to drop it off the base/face of the earth. </div><div dir="auto"><br></div><div dir="auto">This proposal is DOA. </div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 30, 2018 at 11:03 AM Vanessa McHale <<a href="mailto:vanessa.mchale@iohk.io" rel="noreferrer" target="_blank">vanessa.mchale@iohk.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <p>Saying "people shouldn't be using this API in library code" seems
      like a poor reason to potentially break (working?) packages
      downstream. <br>
    </p></div><div text="#000000" bgcolor="#FFFFFF">
    <div class="m_5480242021616763475m_3316461318874844525m_-7681853225840409950moz-cite-prefix">On 10/30/18 7:42 AM, Andrew Martin
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">The benefit is certainly small, and it probably
        would discourage using the API. I don't think that the migration
        path would be tricky. The new package would just reexport
        Text.Printf when built with base < 4.13, and it would define
        it when built with base >= 4.13. All that is required is a
        build-depends line. However, people really shouldn't be using
        this API in library code. Other modules in base provide more
        efficient and more type-safe ways handle most of the situations
        I've seen this used for.
        <div> 
          <div>I've never used System.Console.GetOpt (I'm typically use
            optparse-applicative for option parsing), but yes, I think
            that would also be a good candidate. Since there are
            multiple competing approach for argument parsing in the
            haskell ecosystem, my preference would be to avoid blessing
            any of them with inclusion in base.</div>
        </div>
        <div><br>
        </div>
        <div>I don't feel particularly strongly about either of these,
          but their position in base feels odd. They both feel like the
          result of applying a "batteries included" mindset to a
          standard library that has by and large refrained from
          including batteries.</div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr">On Tue, Oct 30, 2018 at 8:17 AM Herbert Valerio
          Riedel <<a href="mailto:hvriedel@gmail.com" rel="noreferrer" target="_blank">hvriedel@gmail.com</a>> wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
          On 2018-10-30 at 08:04:59 -0400, Andrew Martin wrote:<br>
          > Here's an idea for this I had last night. It's narrowly
          scoped, but I think<br>
          > it moves us a tiny bit in the right direction. We could
          move Text.Printf<br>
          > out of base and into its own library. This doesn't really
          belong in base.<br>
          > The interface it provides it somewhat opinionated, and
          it's not even<br>
          > type-safe. The new library could be named `printf` and
          could live under the<br>
          > haskell github organization. Any thoughts for or against?<br>
          <br>
          Ok, but what does this effectively achieve?<br>
          <br>
          Text.Printf is an API that has been extremely stable and
          doesn't<br>
          significant evolve anymore; I don't think it has contributed
          to major<br>
          ver bumps in recent times, nor is it likely to. So I don't see
          much of a<br>
          compelling benefit in doing so. The effect I'd expect if we do
          this is<br>
          that `Text.Printf` will be reached for less (which some might
          argue to<br>
          be a desirable effect -- but you're effectively pushing this
          API to a<br>
          path of slow legacy death due to reduced discoverability,
          IMO), as the<br>
          convenience of using it is reduced by requiring adding and
          maintaining<br>
          an additional `build-depends` line to your package
          descriptions, as well<br>
          as having to deal with the subtly tricky business of handling
          the<br>
          migration path pre/post-split (c.f. the `network-bsd` split
          currently<br>
          being in progress).<br>
          <br>
          Btw, a related extremely stable API in base I could think of
          which<br>
          people might argue doesn't belong into `base` either is maybe<br>
          `System.Console.GetOpt`; would you argue to split that off as
          well?<br>
          _______________________________________________<br>
          Libraries mailing list<br>
          <a href="mailto:Libraries@haskell.org" rel="noreferrer" target="_blank">Libraries@haskell.org</a><br>
          <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
        </blockquote>
      </div>
      <br clear="all">
      <div><br>
      </div>
      -- <br>
      <div dir="ltr" class="m_5480242021616763475m_3316461318874844525m_-7681853225840409950gmail_signature" data-smartmail="gmail_signature">-Andrew Thaddeus Martin</div>
      <br>
      <fieldset class="m_5480242021616763475m_3316461318874844525m_-7681853225840409950mimeAttachmentHeader"></fieldset>
      <pre class="m_5480242021616763475m_3316461318874844525m_-7681853225840409950moz-quote-pre">_______________________________________________
Libraries mailing list
<a class="m_5480242021616763475m_3316461318874844525m_-7681853225840409950moz-txt-link-abbreviated" href="mailto:Libraries@haskell.org" rel="noreferrer" target="_blank">Libraries@haskell.org</a>
<a class="m_5480242021616763475m_3316461318874844525m_-7681853225840409950moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a>
</pre>
    </blockquote>
  </div>

_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div>