Whither split base?

[Daniel Cartwright]

DOA seems kinda harsh at this point. If base just re-exports the stuff,
that makes sense, but wouldn't we want to move it out eventually?



On Tue, Oct 30, 2018, 11:29 AM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> Yeah
>
> The point ofnsplit base as an idea or goal is to make base simply reexport
> stuff.  Not to drop it off the base/face of the earth.
>
> This proposal is DOA.
>
> On Tue, Oct 30, 2018 at 11:03 AM Vanessa McHale <vanessa.mchale at iohk.io>
> wrote:
>
>> 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> 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
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>>
>>
>> --
>> -Andrew Thaddeus Martin
>>
>> _______________________________________________
>> Libraries mailing listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
> _______________________________________________
> 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/3c25eb4e/attachment.html>