<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body 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 class="moz-cite-prefix">On 10/30/18 7:42 AM, Andrew Martin
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CABNC7eNbrm_0HoD=5qvZqLFsdBS3HJUBqGKG_iBaAD8tBELaVQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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"
            moz-do-not-send="true">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" target="_blank"
            moz-do-not-send="true">Libraries@haskell.org</a><br>
          <a
            href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries"
            rel="noreferrer" target="_blank" moz-do-not-send="true">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
        </blockquote>
      </div>
      <br clear="all">
      <div><br>
      </div>
      -- <br>
      <div dir="ltr" class="gmail_signature"
        data-smartmail="gmail_signature">-Andrew Thaddeus Martin</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>