Whither split base?

Tue Oct 30 19:10:38 UTC 2018

i think i prefer the 'unique' package because it doesn't rely on blocking

On Tue, Oct 30, 2018 at 3:08 PM Theodore Lief Gannon <tanuki at gmail.com>
wrote:

> Stable perhaps, but not uncontested:
>
>
> http://hackage.haskell.org/package/vault-0.3.1.2/docs/Data-Unique-Really.html
>
> (Apologies for off-list duplicate. Why does gmail have different reply
> defaults for desktop vs. mobile...)
>
> On Tue, Oct 30, 2018 at 7:59 AM Vanessa McHale <vanessa.mchale at iohk.io>
> wrote:
>
>> I think this would raise the same objection that Herbert raised before,
>> namely: what does this accomplish when Data.Unique is already stable?
>> All I see happening is that this breaks libraries downstream.
>> On 10/30/18 9:03 AM, Daniel Cartwright wrote:
>>
>> Data.Unique could probably be split off.
>>
>> A few modules that depend on the event manager might have to be split off
>> (e.g. System.Timeout)
>>
>> Control.Concurrent is weird because it also has the 'Fd' stuff in it, not
>> sure how that would work - split off into the event manager package? since
>> there's a cyclic dependency there while those exist in Control.Concurrent.
>>
>> Weak ptrs and Stablenames are basically wrappers around primops, so i'm
>> unsure if those should stay or go.
>>
>> On Tue, Oct 30, 2018 at 9:40 AM Daniel Cartwright <chessai1996 at gmail.com>
>> wrote:
>>
>>> 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
>>>>
>>>
>> _______________________________________________
>> 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/9293f5d2/attachment.html>