its simple: trying to reduce the coupling / interdependency of different pieces of base so they can literally be (at least internally) structured as distinct packages / libraries (so as to fascilitate better experimentation or support for exotic platforms) On Mon, Oct 29, 2018 at 6:46 PM Daniel Cartwright wrote:

Could someone articulate on this "split base"? What does this mean exactly? Having one or more versions of officially supported 'base'-like libraries?

On Mon, Oct 29, 2018, 6:17 PM Edward Kmett wrote:

...

We had two different people join the CLC with the express wish of working on it. Both of them seemed to recoil at the scale of the problem after going deeper, and progress ground to a halt.

We _do_ have a few open slots on the committee though. I'm putting out an open call for folks to join the committee today. Maybe someone interested in diving into the problem might apply. =)

-Edward

On Fri, Oct 26, 2018 at 12:06 AM Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

I just remembered that it was one of the ongoing things the CLC was involved with, for a while. Has there been recent action there ? _______________________________________________ Libraries mailing list 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

Development in this direction is an open process. The key would be finding sufficient will amongst members of the community to make it happen. -Edward On Mon, Oct 29, 2018 at 7:09 PM Daniel Cartwright wrote:

interesting, makes sense. can anyone volunteer?

On Mon, Oct 29, 2018 at 6:53 PM Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

its simple: trying to reduce the coupling / interdependency of different pieces of base so they can literally be (at least internally) structured as distinct packages / libraries (so as to fascilitate better experimentation or support for exotic platforms)

On Mon, Oct 29, 2018 at 6:46 PM Daniel Cartwright wrote:

...

Could someone articulate on this "split base"? What does this mean exactly? Having one or more versions of officially supported 'base'-like libraries?

On Mon, Oct 29, 2018, 6:17 PM Edward Kmett wrote:

...

We had two different people join the CLC with the express wish of working on it. Both of them seemed to recoil at the scale of the problem after going deeper, and progress ground to a halt.

We _do_ have a few open slots on the committee though. I'm putting out an open call for folks to join the committee today. Maybe someone interested in diving into the problem might apply. =)

-Edward

On Fri, Oct 26, 2018 at 12:06 AM Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

I just remembered that it was one of the ongoing things the CLC was involved with, for a while. Has there been recent action there ? _______________________________________________ Libraries mailing list 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

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? On Mon, Oct 29, 2018 at 7:18 PM Daniel Cartwright wrote:

Ah! That's a cool point about backpack. I would like to volunteer to help with this.

On Mon, Oct 29, 2018 at 7:13 PM Edward Kmett wrote:

...

Development in this direction is an open process. The key would be finding sufficient will amongst members of the community to make it happen.

-Edward

On Mon, Oct 29, 2018 at 7:09 PM Daniel Cartwright wrote:

...

interesting, makes sense. can anyone volunteer?

On Mon, Oct 29, 2018 at 6:53 PM Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

its simple: trying to reduce the coupling / interdependency of different pieces of base so they can literally be (at least internally) structured as distinct packages / libraries (so as to fascilitate better experimentation or support for exotic platforms)

On Mon, Oct 29, 2018 at 6:46 PM Daniel Cartwright < chessai1996@gmail.com> wrote:

...

Could someone articulate on this "split base"? What does this mean exactly? Having one or more versions of officially supported 'base'-like libraries?

On Mon, Oct 29, 2018, 6:17 PM Edward Kmett wrote:

...

We had two different people join the CLC with the express wish of working on it. Both of them seemed to recoil at the scale of the problem after going deeper, and progress ground to a halt.

We _do_ have a few open slots on the committee though. I'm putting out an open call for folks to join the committee today. Maybe someone interested in diving into the problem might apply. =)

-Edward

On Fri, Oct 26, 2018 at 12:06 AM Carter Schonwald < carter.schonwald@gmail.com> wrote:

> I just remembered that it was one of the ongoing things the CLC was > involved with, for a while. Has there been recent action there ? > _______________________________________________ > Libraries mailing list > 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

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

-- -Andrew Thaddeus Martin

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 wrote:

...

Here's an idea for this I had last night. It's narrowly scoped, but I

...

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

On 2018-10-30 at 08:04:59 -0400, Andrew Martin wrote: think 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 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- -Andrew Thaddeus Martin

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

...

...

Here's an idea for this I had last night. It's narrowly scoped, but I

...

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

On 2018-10-30 at 08:04:59 -0400, Andrew Martin wrote: think 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 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- -Andrew Thaddeus Martin

-- -Andrew Thaddeus Martin

-- -Andrew Thaddeus Martin

I agree with those. On Tue, Oct 30, 2018 at 9:35 AM Andrew Martin 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 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 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 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@gmail.com> 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

On 2018-10-30 at 08:04:59 -0400, Andrew Martin wrote: 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 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 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

The typeable API in Type.* might be able to go into its own package. I think one of the reasons that Joachim's past attempt was unsuccessful ( https://github.com/nomeata/packages-base) is that it tried to be too modular. If we focus on a fewer number of chunks, it would be perhaps easier. On Tue, Oct 30, 2018 at 10: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 wrote:

...

I agree with those.

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

Stable perhaps, but not uncontested: http://hackage.haskell.org/package/vault-0.3.1.2/docs/Data-Unique-Really.htm... (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 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 wrote:

...

I agree with those.

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

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

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

This would break a lot of packages for the relatively small benefit of finer grained dependencies. On 10/30/18 8:35 AM, Andrew Martin 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 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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 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 wrote:

...

...

Here's an idea for this I had last night. It's narrowly scoped, but I

...

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

...

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

On 2018-10-30 at 08:04:59 -0400, Andrew Martin wrote: think base. 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 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- -Andrew Thaddeus Martin

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

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

We could have some sort of "base-base", the pared down core, and base, the existing core that provides all modules that it currently provides. This seems pretty essential for backwards compatibility if we don't want to break the world. Since there would be conflicts between the modules provided by base and the modules provided by its component packages, projects would have to choose one (e.g. just use base) or the other (e.g. use the component packages a la carte), or use package imports... or somehow teach ghc that these modules are the same and it doesn't matter where they come from. -- Dan Burton On Tue, Oct 30, 2018 at 11:32 AM Daniel Cartwright 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@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 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@gmail.com> wrote:

...

...

Here's an idea for this I had last night. It's narrowly scoped, but I

...

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

On 2018-10-30 at 08:04:59 -0400, Andrew Martin wrote: think 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 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- -Andrew Thaddeus Martin

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

_______________________________________________ Libraries mailing list 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

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

I think the problem with different stability in different parts of base is that it makes it very difficult for package maintainers to get an accurate set of bounds. If you writebase >= 4.8 && < 5you may later need to revise the bounds, and if you write base >= 4.8 && < 4.12 you will likely have bounds be too strict (which may not be revised for every package version...). I had the impression that splitting base would be done using backpack, so that you could provide alternate base implementations for e.g. GHCJS. There's a 4 year-old trac ticket here https://ghc.haskell.org/trac/ghc/ticket/10266 which has some other stuff. There, it talks about user-provided base implementations as the advantage rather than versioning. I think this approach is likely to provide the biggest improvements without breaking anything. On 10/30/18 12:37 PM, Sven Panne wrote:

Am Di., 30. Okt. 2018 um 16:32 Uhr schrieb Daniel Cartwright mailto:chessai1996@gmail.com>:

DOA seems kinda harsh at this point.

I think "DOA" is the right description for every proposal touching the foundations of a language ecosystem in an incompatible way *unless* there are very, very good reasons to break things. And even then, you should better have a good migration story. Python 3 anybody?  

If base just re-exports the stuff, that makes sense, but wouldn't we want to move it out eventually?

Hmmm, what problem exactly should be solved by splitting base? Has this been written down somewhere? Edward mentioned different stability in different parts of base, which is certainly true, but do we have concrete convincing examples of problems caused by that? Does a migration story exist? I just want to remind everybody about the trouble and effort involved in pushing the AMP and FTP through the ecosystem, which are probably peanuts compared to a reorganization of base...

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

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

...

...

Here's an idea for this I had last night. It's narrowly scoped, but I

...

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

On 2018-10-30 at 08:04:59 -0400, Andrew Martin wrote: think 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 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- -Andrew Thaddeus Martin

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

_______________________________________________ Libraries mailing list 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

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

FWIW, I'm very much in favour of Ed's suggestion. A monolithic base creates too much friction for things like porting or introducing newcomers like myself to making contributions to base. I am however interested in why they believe introducing backpack to base should cause breaking changes. Discussions there, I believe would be illuminating. Cheers John On Sat, 3 Nov 2018 at 03:01, 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

...

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

...

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@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@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@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@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

...

...

...

...

...

convenience of using it is reduced by requiring adding and

On 10/30/18, Edward Kmett wrote: pure the 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 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- -Andrew Thaddeus Martin

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

_______________________________________________ Libraries mailing list 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

_______________________________________________ Libraries mailing list 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

Indeed. It’d make it easier for experienced folks to improve / experiment with base. One hopes ! Currently even regular ghc contributors have to wrestle with avoiding needing recursive modules sometimes when hacking on base! There’s still some of those in base but it’s less bad than in the past. Though some changes have very non intuitive realizations / factoring to avoid introducing new recursion. On Sun, Nov 4, 2018 at 10:15 AM Vanessa McHale wrote:

I don't think split base would make it easier to introduce newcomers to making contributions to base.

The argument r.e. portability/backpack is that it would make it harder to use base with other compilers. On 11/2/18 8:09 PM, John Ky wrote:

FWIW, I'm very much in favour of Ed's suggestion.

A monolithic base creates too much friction for things like porting or introducing newcomers like myself to making contributions to base.

I am however interested in why they believe introducing backpack to base should cause breaking changes.

Discussions there, I believe would be illuminating.

Cheers

John

On Sat, 3 Nov 2018 at 03:01, 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

...

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

...

haskell components like the 'printf', but I can well understand how

...

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@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@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@iohk.io> wrote:

...

Saying "people shouldn't be using this API in library code" seems

...

...

...

...

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@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

...

...

...

...

> convenience of using it is reduced by requiring adding and

On 10/30/18, Edward Kmett wrote: pure these like the 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 > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >

-- -Andrew Thaddeus Martin

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

_______________________________________________ Libraries mailing list 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

_______________________________________________ Libraries mailing list 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

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

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

thanks, thats a good point Ian, :) On Thu, Nov 22, 2018 at 6:49 PM Ian Lynagh wrote:

On Tue, Oct 30, 2018 at 01:16:56PM +0100, Herbert Valerio Riedel wrote:

...

On 2018-10-30 at 08:04:59 -0400, Andrew Martin wrote:

...

We could move Text.Printf out of base and into its own library.

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)

I wonder whether you would support moving this into base if it weren't there already.

I don't think the death argument scales. We can't put all modules that someone doesn't want to die into base, or it will become huge. If printf doesn't survive in a level playing field, as a separate library with all the other non-base libraries, then it probably deserves to die.

My opinion is that base should be made as small as possible, to make it (and its internal dependencies) easier to understand and maintain, and faster to build.

Thanks Ian

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