Whither split base?

Fri Nov 2 17:36:52 UTC 2018

I believe Eta supports it now, no?

On 11/2/18 11:01 AM, Tom Murphy wrote:
> 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
>>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-------------- 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/20181102/9c442aa1/attachment.sig>