<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>I think this would raise the same objection that Herbert raised
      before, namely: what does this accomplish when <tt>Data.Unique</tt>
      is already stable? All I see happening is that this breaks
      libraries downstream. <br>
    </p>
    <div class="moz-cite-prefix">On 10/30/18 9:03 AM, Daniel Cartwright
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAD34_kK6xS5kTdPpiEToGwwV=-GYEUiV4K2OPh_eWHaRXCtnsA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">Data.Unique could probably be split off.
        <div><br>
        </div>
        <div>A few modules that depend on the event manager might have
          to be split off (e.g. System.Timeout)</div>
        <div><br>
        </div>
        <div>Control.Concurrent is weird because it also has the 'Fd'
          stuff in it, not sure how that would work - split off into the
          event manager package? since there's a cyclic dependency there
          while those exist in Control.Concurrent.</div>
        <div><br>
        </div>
        <div>Weak ptrs and Stablenames are basically wrappers around
          primops, so i'm unsure if those should stay or go.</div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr">On Tue, Oct 30, 2018 at 9:40 AM Daniel Cartwright
          <<a href="mailto:chessai1996@gmail.com"
            moz-do-not-send="true">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="ltr">I agree with those.</div>
          <br>
          <div class="gmail_quote">
            <div dir="ltr">On Tue, Oct 30, 2018 at 9:35 AM Andrew Martin
              <<a href="mailto:andrew.thaddeus@gmail.com"
                target="_blank" moz-do-not-send="true">andrew.thaddeus@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="ltr">Here's my stab at a more aggressive split:
                <div><br>
                </div>
                <div>* base: everything not removed by the libraries
                  below</div>
                <div>* concurrency: all Control.Concurrent.* modules
                  (depends on base)</div>
                <div>* foreign: all Foreign.* modules (depends on base)</div>
                <div>* event-manager: all GHC.IO.* modules,
                  System.Timeout (depends on base, foreign, concurrency)</div>
                <div><br>
                </div>
                <div>There would be some additional trickery. The stuff
                  in Control.Concurrent that deals with event
                  registration would need to be moved somewhere else.
                  But I think this would more-or-less work.</div>
              </div>
              <br>
              <div class="gmail_quote">
                <div dir="ltr">On Tue, Oct 30, 2018 at 8:54 AM Andrew
                  Martin <<a href="mailto:andrew.thaddeus@gmail.com"
                    target="_blank" moz-do-not-send="true">andrew.thaddeus@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="ltr">For additional clarity, I should
                    mention that I am looking for low-hanging fruit
                    here. The higher and tastier fruit would of course
                    be splitting out the event manager and all the file
                    handle logic with it. But that would be difficult,
                    both in terms of the actual work required and in
                    terms of achieving a consensus.</div>
                  <br>
                  <div class="gmail_quote">
                    <div dir="ltr">On Tue, Oct 30, 2018 at 8:47 AM
                      Andrew Martin <<a
                        href="mailto:andrew.thaddeus@gmail.com"
                        target="_blank" moz-do-not-send="true">andrew.thaddeus@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="ltr">We could also move out all the
                        modules underneath Control.Concurrent (but not
                        Control.Concurrent itself) except for the MVar
                        module. We would have to leave that one because
                        there is a bunch of other stuff in base that
                        uses MVar. These modules have demonstrated less
                        stability than System.Console.GetOpt and
                        Text.Printf, and there are competing
                        implementations in other libraries.</div>
                      <br>
                      <div class="gmail_quote">
                        <div dir="ltr">On Tue, Oct 30, 2018 at 8:42 AM
                          Andrew Martin <<a
                            href="mailto:andrew.thaddeus@gmail.com"
                            target="_blank" moz-do-not-send="true">andrew.thaddeus@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="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"
                                target="_blank" 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="m_2484095845074977511m_3357338627103819532m_5728837890627266443m_7007428628053109112m_6505248671778253220gmail_signature"
                            data-smartmail="gmail_signature">-Andrew
                            Thaddeus Martin</div>
                        </blockquote>
                      </div>
                      <br clear="all">
                      <div><br>
                      </div>
                      -- <br>
                      <div dir="ltr"
class="m_2484095845074977511m_3357338627103819532m_5728837890627266443m_7007428628053109112gmail_signature"
                        data-smartmail="gmail_signature">-Andrew
                        Thaddeus Martin</div>
                    </blockquote>
                  </div>
                  <br clear="all">
                  <div><br>
                  </div>
                  -- <br>
                  <div dir="ltr"
class="m_2484095845074977511m_3357338627103819532m_5728837890627266443gmail_signature"
                    data-smartmail="gmail_signature">-Andrew Thaddeus
                    Martin</div>
                </blockquote>
              </div>
              <br clear="all">
              <div><br>
              </div>
              -- <br>
              <div dir="ltr"
                class="m_2484095845074977511m_3357338627103819532gmail_signature"
                data-smartmail="gmail_signature">-Andrew Thaddeus Martin</div>
              _______________________________________________<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>
        </blockquote>
      </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>