Whither split base?

[Daniel Cartwright]

I agree with those.

On Tue, Oct 30, 2018 at 9:35 AM Andrew Martin <andrew.thaddeus at gmail.com>
wrote:

> Here's my stab at a more aggressive split:
>
> * base: everything not removed by the libraries below
> * concurrency: all Control.Concurrent.* modules (depends on base)
> * foreign: all Foreign.* modules (depends on base)
> * event-manager: all GHC.IO.* modules, System.Timeout (depends on base,
> foreign, concurrency)
>
> There would be some additional trickery. The stuff in Control.Concurrent
> that deals with event registration would need to be moved somewhere else.
> But I think this would more-or-less work.
>
> On Tue, Oct 30, 2018 at 8:54 AM Andrew Martin <andrew.thaddeus at gmail.com>
> wrote:
>
>> For additional clarity, I should mention that I am looking for
>> low-hanging fruit here. The higher and tastier fruit would of course be
>> splitting out the event manager and all the file handle logic with it. But
>> that would be difficult, both in terms of the actual work required and in
>> terms of achieving a consensus.
>>
>> On Tue, Oct 30, 2018 at 8:47 AM Andrew Martin <andrew.thaddeus at gmail.com>
>> wrote:
>>
>>> We could also move out all the modules underneath Control.Concurrent
>>> (but not Control.Concurrent itself) except for the MVar module. We would
>>> have to leave that one because there is a bunch of other stuff in base that
>>> uses MVar. These modules have demonstrated less stability than
>>> System.Console.GetOpt and Text.Printf, and there are competing
>>> implementations in other libraries.
>>>
>>> On Tue, Oct 30, 2018 at 8:42 AM Andrew Martin <andrew.thaddeus at gmail.com>
>>> 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
>>>>
>>>
>>>
>>> --
>>> -Andrew Thaddeus Martin
>>>
>>
>>
>> --
>> -Andrew Thaddeus Martin
>>
>
>
> --
> -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/109d448f/attachment.html>