Whither split base?
Vanessa McHale
vanessa.mchale at iohk.io
Tue Oct 30 14:59:18 UTC 2018
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 <mailto: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 <mailto: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 <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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 <mailto: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/13997c16/attachment-0001.html>
-------------- 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/20181030/13997c16/attachment-0001.sig>
More information about the Libraries
mailing list