Re: Whither split base?

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 mailto:hvriedel@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@haskell.org mailto:Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- -Andrew Thaddeus Martin

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries