Whither split base?

[Vanessa McHale]

Saying "people shouldn't be using this API in library code" seems like a
poor reason to potentially break (working?) packages downstream.

On 10/30/18 7:42 AM, Andrew Martin wrote:
> 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.
>  
> 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.
>
> 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.
>
> On Tue, Oct 30, 2018 at 8:17 AM Herbert Valerio Riedel
> <hvriedel at gmail.com <mailto:hvriedel at gmail.com>> wrote:
>
>
>     On 2018-10-30 at 08:04:59 -0400, Andrew Martin wrote:
>     > Here's an idea for this I had last night. It's narrowly scoped,
>     but I think
>     > it moves us a tiny bit in the right direction. We could move
>     Text.Printf
>     > out of base and into its own library. This doesn't really belong
>     in base.
>     > The interface it provides it somewhat opinionated, and it's not even
>     > type-safe. The new library could be named `printf` and could
>     live under the
>     > haskell github organization. Any thoughts for or against?
>
>     Ok, but what does this effectively achieve?
>
>     Text.Printf is an API that has been extremely stable and doesn't
>     significant evolve anymore; I don't think it has contributed to major
>     ver bumps in recent times, nor is it likely to. So I don't see
>     much of a
>     compelling benefit in doing so. The effect I'd expect if we do this is
>     that `Text.Printf` will be reached for less (which some might argue to
>     be a desirable effect -- but you're effectively pushing this API to a
>     path of slow legacy death due to reduced discoverability, IMO), as the
>     convenience of using it is reduced by requiring adding and maintaining
>     an additional `build-depends` line to your package descriptions,
>     as well
>     as having to deal with the subtly tricky business of handling the
>     migration path pre/post-split (c.f. the `network-bsd` split currently
>     being in progress).
>
>     Btw, a related extremely stable API in base I could think of which
>     people might argue doesn't belong into `base` either is maybe
>     `System.Console.GetOpt`; would you argue to split that off as well?
>     _______________________________________________
>     Libraries mailing list
>     Libraries at haskell.org <mailto:Libraries at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
>
> -- 
> -Andrew Thaddeus Martin
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20181030/ff692e42/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20181030/ff692e42/attachment.sig>