Re: Whither split base?

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 mailto:chessai1996@gmail.com> wrote:

I agree with those.

On Tue, Oct 30, 2018 at 9:35 AM Andrew Martin mailto:andrew.thaddeus@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 mailto:andrew.thaddeus@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 mailto:andrew.thaddeus@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 mailto:andrew.thaddeus@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 mailto:hvriedel@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@haskell.org mailto:Libraries@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@haskell.org mailto:Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries