Whither split base?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Whither split base?

Carter Schonwald
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Whither split base?

Vanessa McHale

I'd be quite happy to see a split base as well. Would this make it easier to target exotic architectures + operating systems?

On 10/25/18 11:05 PM, Carter Schonwald 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Whither split base?

Henning Thielemann

On Thu, 25 Oct 2018, Vanessa McHale wrote:

> I'd be quite happy to see a split base as well. Would this make it
> easier to target exotic architectures + operating systems?

Surprisingly splitting 'base' was a wish I recently entered into the GHC
development direction questionnaire.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Whither split base?

Edward Kmett-2
In reply to this post by Carter Schonwald
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Whither split base?

chessai .
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Whither split base?

Carter Schonwald
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Whither split base?

chessai .
interesting, makes sense. can anyone volunteer?

On Mon, Oct 29, 2018 at 6:53 PM Carter Schonwald <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Whither split base?

Edward Kmett-2
In reply to this post by chessai .
There are lots of parts of base that evolve at radically different speeds.

It'd be nice if these could be versioned separately. Then code that only depends on stable portions of base could properly still follow the PVP in their bounds rather than the (base <5) bounds that everybody uses and still not break with _every_ GHC release, which currently slavishly updates the major version number every release.

It'd also be nice if base was somehow splintered into smaller components. This could enable things like GHCJS/Eta support in a more principled way. Backpack could be instrumental to accomplishing this. e.g. consider that each of those wants Text implemented a different way, and the same can be extrapolated over much of base's FFI support.

However, the main stumbling block is that base is huge, and is riddled with cyclic dependencies, splitting it up into components without cycles between them that somehow respect all of the current power of base is no small task.

When previous attempts were made backpack wasn't in a usable state yet. It may well be more tractable today.

-Edward

On Mon, Oct 29, 2018 at 6:46 PM Daniel Cartwright <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Whither split base?

Edward Kmett-2
In reply to this post by chessai .
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 <[hidden email]> wrote:
interesting, makes sense. can anyone volunteer?

On Mon, Oct 29, 2018 at 6:53 PM Carter Schonwald <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Whither split base?

chessai .
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 <[hidden email]> 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 <[hidden email]> wrote:
interesting, makes sense. can anyone volunteer?

On Mon, Oct 29, 2018 at 6:53 PM Carter Schonwald <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Whither split base?

Andrew Martin
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
interesting, makes sense. can anyone volunteer?

On Mon, Oct 29, 2018 at 6:53 PM Carter Schonwald <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
-Andrew Thaddeus Martin

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Whither split base?

Herbert Valerio Riedel-3

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Whither split base?

Andrew 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
-Andrew Thaddeus Martin

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Whither split base?

Andrew Martin
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
-Andrew Thaddeus Martin


--
-Andrew Thaddeus Martin

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Whither split base?

Andrew 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
-Andrew Thaddeus Martin


--
-Andrew Thaddeus Martin


--
-Andrew Thaddeus Martin

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Whither split base?

Andrew Martin
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
-Andrew Thaddeus Martin


--
-Andrew Thaddeus Martin


--
-Andrew Thaddeus Martin


--
-Andrew Thaddeus Martin

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Whither split base?

chessai .
I agree with those.

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


--
-Andrew Thaddeus Martin


--
-Andrew Thaddeus Martin


--
-Andrew Thaddeus Martin


--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Whither split base?

chessai .
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 <[hidden email]> wrote:
I agree with those.

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


--
-Andrew Thaddeus Martin


--
-Andrew Thaddeus Martin


--
-Andrew Thaddeus Martin


--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Whither split base?

chessai .
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 <[hidden email]> 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 <[hidden email]> wrote:
I agree with those.

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


--
-Andrew Thaddeus Martin


--
-Andrew Thaddeus Martin


--
-Andrew Thaddeus Martin


--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Whither split base?

Vanessa McHale
In reply to this post by Andrew Martin

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
-Andrew Thaddeus Martin


--
-Andrew Thaddeus Martin


--
-Andrew Thaddeus Martin


--
-Andrew Thaddeus Martin

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

signature.asc (499 bytes) Download Attachment
12