<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">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">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">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><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_6505248671778253220gmail_signature" data-smartmail="gmail_signature">-Andrew Thaddeus Martin</div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">-Andrew Thaddeus Martin</div>