Whither split base?

[Tom Murphy]

I'd rather see Backpack become a lot more mainstream (many more
packages using it, maybe seeing other Haskell compilers implement it?)
before using it to split base.

I'm also -1 on any change to our most foundational package that causes
breakage for any category of users, unless there's a very compelling
reason.

Tom

On 10/30/18, Edward Kmett <ekmett at gmail.com> wrote:
> Now that we have backpack which gives us 'reexported-modules:' perhaps a
> better plan for a split-base would be rather to leave base monolithic, with
> its current API, but instead eyeball having it re-export most if not all of
> itself from smaller split-base components?
>
> I'm mostly interested in foundational wins where splitting things up
> enables us to run in more places because you have to port fewer parts, and
> less about wins that we get from splintering off small but completely pure
> haskell components like the 'printf', but I can well understand how these
> concerns get conflated.
>
> Then Herbert's (valid) objection about needless breakage is addressed and
> it still provides a roadmap to a finer-grained dependency set nonetheless.
>
> -Edward
>
> On Tue, Oct 30, 2018 at 11:32 AM Daniel Cartwright <chessai1996 at gmail.com>
> wrote:
>
>> 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
>>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>