Discussion:
Whither split base?
Add Reply
Carter Schonwald
2018-10-26 04:05:47 UTC
Reply
Permalink
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 ?
Vanessa McHale
2018-10-26 04:16:17 UTC
Reply
Permalink
I'd be quite happy to see a split base as well. Would this make it
easier to target exotic architectures + operating systems?
Post by 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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Henning Thielemann
2018-10-26 08:52:50 UTC
Reply
Permalink
Post by 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?
Surprisingly splitting 'base' was a wish I recently entered into the GHC
development direction questionnaire.
Edward Kmett
2018-10-29 22:17:02 UTC
Reply
Permalink
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 <
Post by 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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Daniel Cartwright
2018-10-29 22:46:27 UTC
Reply
Permalink
Could someone articulate on this "split base"? What does this mean exactly?
Having one or more versions of officially supported 'base'-like libraries?
Post by Edward Kmett
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 <
Post by 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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Carter Schonwald
2018-10-29 22:53:40 UTC
Reply
Permalink
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)
Post by Daniel Cartwright
Could someone articulate on this "split base"? What does this mean
exactly? Having one or more versions of officially supported 'base'-like
libraries?
Post by Edward Kmett
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 <
Post by 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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Daniel Cartwright
2018-10-29 23:08:51 UTC
Reply
Permalink
interesting, makes sense. can anyone volunteer?
Post by 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)
Post by Daniel Cartwright
Could someone articulate on this "split base"? What does this mean
exactly? Having one or more versions of officially supported 'base'-like
libraries?
Post by Edward Kmett
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 <
Post by 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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Edward Kmett
2018-10-29 23:13:37 UTC
Reply
Permalink
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
Post by Daniel Cartwright
interesting, makes sense. can anyone volunteer?
On Mon, Oct 29, 2018 at 6:53 PM Carter Schonwald <
Post by 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)
Post by Daniel Cartwright
Could someone articulate on this "split base"? What does this mean
exactly? Having one or more versions of officially supported 'base'-like
libraries?
Post by Edward Kmett
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 <
Post by 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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Daniel Cartwright
2018-10-29 23:17:35 UTC
Reply
Permalink
Ah! That's a cool point about backpack. I would like to volunteer to help
with this.
Post by Edward Kmett
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
Post by Daniel Cartwright
interesting, makes sense. can anyone volunteer?
On Mon, Oct 29, 2018 at 6:53 PM Carter Schonwald <
Post by 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)
Post by Daniel Cartwright
Could someone articulate on this "split base"? What does this mean
exactly? Having one or more versions of officially supported 'base'-like
libraries?
Post by Edward Kmett
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 <
Post by 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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Andrew Martin
2018-10-30 12:04:59 UTC
Reply
Permalink
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?
Post by Daniel Cartwright
Ah! That's a cool point about backpack. I would like to volunteer to help
with this.
Post by Edward Kmett
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
Post by Daniel Cartwright
interesting, makes sense. can anyone volunteer?
On Mon, Oct 29, 2018 at 6:53 PM Carter Schonwald <
Post by 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 <
Post by Daniel Cartwright
Could someone articulate on this "split base"? What does this mean
exactly? Having one or more versions of officially supported 'base'-like
libraries?
Post by Edward Kmett
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 <
Post by 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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
Herbert Valerio Riedel
2018-10-30 12:16:56 UTC
Reply
Permalink
Post by 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?
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?
Andrew Martin
2018-10-30 12:42:04 UTC
Reply
Permalink
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.
Post by Herbert Valerio Riedel
Post by Andrew Martin
Here's an idea for this I had last night. It's narrowly scoped, but I
think
Post by Andrew Martin
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
Post by Andrew Martin
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
Andrew Martin
2018-10-30 12:47:24 UTC
Reply
Permalink
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.
Post by 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.
Post by Herbert Valerio Riedel
Post by Andrew Martin
Here's an idea for this I had last night. It's narrowly scoped, but I
think
Post by Andrew Martin
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.
Post by Andrew Martin
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
Post by Andrew Martin
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
Andrew Martin
2018-10-30 12:54:59 UTC
Reply
Permalink
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.
Post by 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.
Post by 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 <
Post by Andrew Martin
Post by Andrew Martin
Here's an idea for this I had last night. It's narrowly scoped, but I
think
Post by Andrew Martin
it moves us a tiny bit in the right direction. We could move
Text.Printf
Post by Andrew Martin
out of base and into its own library. This doesn't really belong in
base.
Post by Andrew Martin
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
Post by Andrew Martin
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
Andrew Martin
2018-10-30 13:35:05 UTC
Reply
Permalink
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.
Post by 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.
Post by 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.
Post by 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 <
Post by Andrew Martin
Post by Andrew Martin
Here's an idea for this I had last night. It's narrowly scoped, but I
think
Post by Andrew Martin
it moves us a tiny bit in the right direction. We could move
Text.Printf
Post by Andrew Martin
out of base and into its own library. This doesn't really belong in
base.
Post by Andrew Martin
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
Post by Andrew Martin
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
Daniel Cartwright
2018-10-30 13:40:55 UTC
Reply
Permalink
I agree with those.
Post by Andrew Martin
* 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.
Post by 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.
Post by 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.
Post by 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 <
Post by Andrew Martin
Post by Andrew Martin
Here's an idea for this I had last night. It's narrowly scoped, but
I think
Post by Andrew Martin
it moves us a tiny bit in the right direction. We could move
Text.Printf
Post by Andrew Martin
out of base and into its own library. This doesn't really belong in
base.
Post by Andrew Martin
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
Post by Andrew Martin
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Daniel Cartwright
2018-10-30 14:03:26 UTC
Reply
Permalink
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.
Post by Daniel Cartwright
I agree with those.
Post by Andrew Martin
* 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.
Post by 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.
Post by 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 <
Post by 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 <
Post by Andrew Martin
Post by Andrew Martin
Here's an idea for this I had last night. It's narrowly scoped, but
I think
Post by Andrew Martin
it moves us a tiny bit in the right direction. We could move
Text.Printf
Post by Andrew Martin
out of base and into its own library. This doesn't really belong in
base.
Post by Andrew Martin
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
Post by Andrew Martin
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Daniel Cartwright
2018-10-30 14:05:51 UTC
Reply
Permalink
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.
Post by Daniel Cartwright
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.
Post by Daniel Cartwright
I agree with those.
Post by Andrew Martin
* 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.
Post by 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 <
Post by 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 <
Post by 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 <
Post by Andrew Martin
Post by Andrew Martin
Here's an idea for this I had last night. It's narrowly scoped,
but I think
Post by Andrew Martin
it moves us a tiny bit in the right direction. We could move
Text.Printf
Post by Andrew Martin
out of base and into its own library. This doesn't really belong
in base.
Post by Andrew Martin
The interface it provides it somewhat opinionated, and it's not
even
Post by Andrew Martin
type-safe. The new library could be named `printf` and could live
under the
Post by Andrew Martin
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Vanessa McHale
2018-10-30 14:59:18 UTC
Reply
Permalink
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.
Post by Daniel Cartwright
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
I agree with those.
On Tue, Oct 30, 2018 at 9:35 AM Andrew Martin
* 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
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
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
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
On 2018-10-30 at 08:04:59 -0400, Andrew Martin
Post by Andrew Martin
Here's an idea for this I had last night.
It's narrowly scoped, but I think
Post by Andrew Martin
it moves us a tiny bit in the right
direction. We could move Text.Printf
Post by Andrew Martin
out of base and into its own library. This
doesn't really belong in base.
Post by Andrew Martin
The interface it provides it somewhat
opinionated, and it's not even
Post by Andrew Martin
type-safe. The new library could be named
`printf` and could live under the
Post by Andrew Martin
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Theodore Lief Gannon
2018-10-30 19:07:57 UTC
Reply
Permalink
Stable perhaps, but not uncontested:

http://hackage.haskell.org/package/vault-0.3.1.2/docs/Data-Unique-Really.html

(Apologies for off-list duplicate. Why does gmail have different reply
defaults for desktop vs. mobile...)
Post by Vanessa McHale
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.
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.
Post by Daniel Cartwright
I agree with those.
Post by Andrew Martin
* 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.
Post by 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 <
Post by 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 <
Post by 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 <
Post by Andrew Martin
Post by Andrew Martin
Here's an idea for this I had last night. It's narrowly scoped,
but I think
Post by Andrew Martin
it moves us a tiny bit in the right direction. We could move
Text.Printf
Post by Andrew Martin
out of base and into its own library. This doesn't really belong
in base.
Post by Andrew Martin
The interface it provides it somewhat opinionated, and it's not
even
Post by Andrew Martin
type-safe. The new library could be named `printf` and could live
under the
Post by Andrew Martin
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Daniel Cartwright
2018-10-30 19:10:38 UTC
Reply
Permalink
i think i prefer the 'unique' package because it doesn't rely on blocking
Post by Theodore Lief Gannon
http://hackage.haskell.org/package/vault-0.3.1.2/docs/Data-Unique-Really.html
(Apologies for off-list duplicate. Why does gmail have different reply
defaults for desktop vs. mobile...)
Post by Vanessa McHale
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.
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.
Post by Daniel Cartwright
I agree with those.
Post by Andrew Martin
* 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 <
Post by 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 <
Post by 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 <
Post by 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 <
Post by Andrew Martin
Post by Andrew Martin
Here's an idea for this I had last night. It's narrowly scoped,
but I think
Post by Andrew Martin
it moves us a tiny bit in the right direction. We could move
Text.Printf
Post by Andrew Martin
out of base and into its own library. This doesn't really belong
in base.
Post by Andrew Martin
The interface it provides it somewhat opinionated, and it's not
even
Post by Andrew Martin
type-safe. The new library could be named `printf` and could live
under the
Post by Andrew Martin
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Vanessa McHale
2018-10-30 14:56:01 UTC
Reply
Permalink
This would break a lot of packages for the relatively small benefit of
finer grained dependencies.
Post by Andrew Martin
* 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
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
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
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
Post by Andrew Martin
Here's an idea for this I had last night. It's
narrowly scoped, but I think
Post by Andrew Martin
it moves us a tiny bit in the right direction. We
could move Text.Printf
Post by Andrew Martin
out of base and into its own library. This doesn't
really belong in base.
Post by Andrew Martin
The interface it provides it somewhat opinionated,
and it's not even
Post by Andrew Martin
type-safe. The new library could be named `printf`
and could live under the
Post by Andrew Martin
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Vanessa McHale
2018-10-30 15:03:14 UTC
Reply
Permalink
Saying "people shouldn't be using this API in library code" seems like a
poor reason to potentially break (working?) packages downstream.
Post by 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
Post by Andrew Martin
Here's an idea for this I had last night. It's narrowly scoped,
but I think
Post by Andrew Martin
it moves us a tiny bit in the right direction. We could move
Text.Printf
Post by Andrew Martin
out of base and into its own library. This doesn't really belong
in base.
Post by Andrew Martin
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
Post by Andrew Martin
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Carter Schonwald
2018-10-30 15:29:13 UTC
Reply
Permalink
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.
Post by Vanessa McHale
Saying "people shouldn't be using this API in library code" seems like a
poor reason to potentially break (working?) packages downstream.
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.
Post by Herbert Valerio Riedel
Post by Andrew Martin
Here's an idea for this I had last night. It's narrowly scoped, but I
think
Post by Andrew Martin
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.
Post by Andrew Martin
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
Post by Andrew Martin
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
_______________________________________________
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Daniel Cartwright
2018-10-30 15:32:11 UTC
Reply
Permalink
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?
Post by Carter Schonwald
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.
Post by Vanessa McHale
Saying "people shouldn't be using this API in library code" seems like a
poor reason to potentially break (working?) packages downstream.
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 <
Post by Andrew Martin
Post by Andrew Martin
Here's an idea for this I had last night. It's narrowly scoped, but I
think
Post by Andrew Martin
it moves us a tiny bit in the right direction. We could move
Text.Printf
Post by Andrew Martin
out of base and into its own library. This doesn't really belong in
base.
Post by Andrew Martin
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
Post by Andrew Martin
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
_______________________________________________
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Dan Burton
2018-10-30 15:49:38 UTC
Reply
Permalink
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
Post by Daniel Cartwright
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 <
Post by Carter Schonwald
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.
Post by Vanessa McHale
Saying "people shouldn't be using this API in library code" seems like a
poor reason to potentially break (working?) packages downstream.
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 <
Post by Andrew Martin
Post by Andrew Martin
Here's an idea for this I had last night. It's narrowly scoped, but I
think
Post by Andrew Martin
it moves us a tiny bit in the right direction. We could move
Text.Printf
Post by Andrew Martin
out of base and into its own library. This doesn't really belong in
base.
Post by Andrew Martin
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
Post by Andrew Martin
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
_______________________________________________
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Sven Panne
2018-10-30 17:37:34 UTC
Reply
Permalink
Am Di., 30. Okt. 2018 um 16:32 Uhr schrieb Daniel Cartwright <
Post by Daniel Cartwright
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?
Post by Daniel Cartwright
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...
Vanessa McHale
2018-10-30 18:49:46 UTC
Reply
Permalink
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.
Am Di., 30. Okt. 2018 um 16:32 Uhr schrieb Daniel Cartwright
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Edward Kmett
2018-10-31 02:50:08 UTC
Reply
Permalink
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
Post by Daniel Cartwright
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 <
Post by Carter Schonwald
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.
Post by Vanessa McHale
Saying "people shouldn't be using this API in library code" seems like a
poor reason to potentially break (working?) packages downstream.
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 <
Post by Andrew Martin
Post by Andrew Martin
Here's an idea for this I had last night. It's narrowly scoped, but I
think
Post by Andrew Martin
it moves us a tiny bit in the right direction. We could move
Text.Printf
Post by Andrew Martin
out of base and into its own library. This doesn't really belong in
base.
Post by Andrew Martin
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
Post by Andrew Martin
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
_______________________________________________
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Tom Murphy
2018-11-02 16:01:35 UTC
Reply
Permalink
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
Post by Edward Kmett
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
Post by Daniel Cartwright
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 <
Post by Carter Schonwald
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.
Post by Vanessa McHale
Saying "people shouldn't be using this API in library code" seems like a
poor reason to potentially break (working?) packages downstream.
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 <
Post by Andrew Martin
Post by Andrew Martin
Here's an idea for this I had last night. It's narrowly scoped, but I
think
Post by Andrew Martin
it moves us a tiny bit in the right direction. We could move
Text.Printf
Post by Andrew Martin
out of base and into its own library. This doesn't really belong in
base.
Post by Andrew Martin
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
Post by Andrew Martin
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Vanessa McHale
2018-11-02 17:36:52 UTC
Reply
Permalink
I believe Eta supports it now, no?
Post by Tom Murphy
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
Post by Edward Kmett
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
Post by Daniel Cartwright
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 <
Post by Carter Schonwald
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.
Post by Vanessa McHale
Saying "people shouldn't be using this API in library code" seems like a
poor reason to potentially break (working?) packages downstream.
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 <
Post by Andrew Martin
Post by Andrew Martin
Here's an idea for this I had last night. It's narrowly scoped, but I
think
Post by Andrew Martin
it moves us a tiny bit in the right direction. We could move
Text.Printf
Post by Andrew Martin
out of base and into its own library. This doesn't really belong in
base.
Post by Andrew Martin
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
Post by Andrew Martin
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
John Ky
2018-11-03 01:09:26 UTC
Reply
Permalink
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
Post by Tom Murphy
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
Post by Edward Kmett
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
Post by Edward Kmett
its current API, but instead eyeball having it re-export most if not all
of
Post by Edward Kmett
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
Post by Edward Kmett
less about wins that we get from splintering off small but completely
pure
Post by Edward Kmett
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.
Post by Edward Kmett
-Edward
On Tue, Oct 30, 2018 at 11:32 AM Daniel Cartwright <
Post by Daniel Cartwright
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 <
Post by Carter Schonwald
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 <
Post by Vanessa McHale
Saying "people shouldn't be using this API in library code" seems like a
poor reason to potentially break (working?) packages downstream.
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
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
package would just reexport Text.Printf when built with base < 4.13,
and
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
it
would define it when built with base >= 4.13. All that is required is
a
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
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 <
Post by Andrew Martin
Post by Andrew Martin
Here's an idea for this I had last night. It's narrowly scoped, but I
think
Post by Andrew Martin
it moves us a tiny bit in the right direction. We could move
Text.Printf
Post by Andrew Martin
out of base and into its own library. This doesn't really belong in
base.
Post by Andrew Martin
The interface it provides it somewhat opinionated, and it's not
even
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
Post by Andrew Martin
type-safe. The new library could be named `printf` and could live
under the
Post by Andrew Martin
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
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
a
compelling benefit in doing so. The effect I'd expect if we do this
is
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
that `Text.Printf` will be reached for less (which some might argue
to
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
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
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
convenience of using it is reduced by requiring adding and
maintaining
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing
mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Vanessa McHale
2018-11-04 15:15:14 UTC
Reply
Permalink
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.
Post by John Ky
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
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
Post by Edward Kmett
Now that we have backpack which gives us 'reexported-modules:'
perhaps a
Post by Edward Kmett
better plan for a split-base would be rather to leave base
monolithic, with
Post by Edward Kmett
its current API, but instead eyeball having it re-export most if
not all of
Post by Edward Kmett
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
Post by Edward Kmett
less about wins that we get from splintering off small but
completely pure
Post by Edward Kmett
haskell components like the 'printf', but I can well understand
how these
Post by Edward Kmett
concerns get conflated.
Then Herbert's (valid) objection about needless breakage is
addressed and
Post by Edward Kmett
it still provides a roadmap to a finer-grained dependency set
nonetheless.
Post by Edward Kmett
-Edward
On Tue, Oct 30, 2018 at 11:32 AM Daniel Cartwright
Post by Daniel Cartwright
DOA seems kinda harsh at this point. If base just re-exports
the stuff,
Post by Edward Kmett
Post by Daniel Cartwright
that makes sense, but wouldn't we want to move it out eventually?
On Tue, Oct 30, 2018, 11:29 AM Carter Schonwald <
Post by Carter Schonwald
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
Post by Vanessa McHale
Saying "people shouldn't be using this API in library code"
seems like
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
a
poor reason to potentially break (working?) packages downstream.
The benefit is certainly small, and it probably would
discourage using
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
the API. I don't think that the migration path would be
tricky. The new
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
package would just reexport Text.Printf when built with base
< 4.13, and
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
it
would define it when built with base >= 4.13. All that is
required is a
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
build-depends line. However, people really shouldn't be using
this API
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
in
library code. Other modules in base provide more efficient
and more
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
type-safe ways handle most of the situations I've seen this
used for.
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
I've never used System.Console.GetOpt (I'm typically use
optparse-applicative for option parsing), but yes, I think
that would
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
also
be a good candidate. Since there are multiple competing
approach for
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
argument parsing in the haskell ecosystem, my preference
would be to
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
avoid
blessing any of them with inclusion in base.
I don't feel particularly strongly about either of these, but
their
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
position in base feels odd. They both feel like the result of
applying
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
a
"batteries included" mindset to a standard library that has
by and
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
large
refrained from including batteries.
On Tue, Oct 30, 2018 at 8:17 AM Herbert Valerio Riedel <
Post by Andrew Martin
Post by Andrew Martin
Here's an idea for this I had last night. It's narrowly
scoped, but
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
Post by Andrew Martin
I
think
Post by Andrew Martin
it moves us a tiny bit in the right direction. We could move
Text.Printf
Post by Andrew Martin
out of base and into its own library. This doesn't really
belong in
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
base.
Post by Andrew Martin
The interface it provides it somewhat opinionated, and
it's not even
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
Post by Andrew Martin
type-safe. The new library could be named `printf` and
could live
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
under the
Post by Andrew Martin
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
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
ver bumps in recent times, nor is it likely to. So I don't
see much of
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
a
compelling benefit in doing so. The effect I'd expect if we
do this is
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
that `Text.Printf` will be reached for less (which some
might argue to
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
be a desirable effect -- but you're effectively pushing this
API to a
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
path of slow legacy death due to reduced discoverability,
IMO), as the
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
convenience of using it is reduced by requiring adding and
maintaining
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
an additional `build-depends` line to your package
descriptions, as
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
well
as having to deal with the subtly tricky business of
handling the
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
migration path pre/post-split (c.f. the `network-bsd` split
currently
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
being in progress).
Btw, a related extremely stable API in base I could think of
which
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
people might argue doesn't belong into `base` either is maybe
`System.Console.GetOpt`; would you argue to split that off
as well?
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing
<http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Carter Schonwald
2018-11-04 16:04:27 UTC
Reply
Permalink
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.
Post by Vanessa McHale
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.
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
Post by Tom Murphy
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
Post by Edward Kmett
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
Post by Edward Kmett
its current API, but instead eyeball having it re-export most if not
all of
Post by Edward Kmett
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
Post by Edward Kmett
less about wins that we get from splintering off small but completely
pure
Post by Edward Kmett
haskell components like the 'printf', but I can well understand how
these
Post by Edward Kmett
concerns get conflated.
Then Herbert's (valid) objection about needless breakage is addressed
and
Post by Edward Kmett
it still provides a roadmap to a finer-grained dependency set
nonetheless.
Post by Edward Kmett
-Edward
On Tue, Oct 30, 2018 at 11:32 AM Daniel Cartwright <
Post by Daniel Cartwright
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 <
Post by Carter Schonwald
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 <
Post by Vanessa McHale
Saying "people shouldn't be using this API in library code" seems
like
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
a
poor reason to potentially break (working?) packages downstream.
The benefit is certainly small, and it probably would discourage
using
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
the API. I don't think that the migration path would be tricky. The
new
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
package would just reexport Text.Printf when built with base < 4.13,
and
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
it
would define it when built with base >= 4.13. All that is required
is a
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
build-depends line. However, people really shouldn't be using this
API
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
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
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
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 <
Post by Andrew Martin
Post by Andrew Martin
Here's an idea for this I had last night. It's narrowly scoped,
but
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
Post by Andrew Martin
I
think
Post by Andrew Martin
it moves us a tiny bit in the right direction. We could move
Text.Printf
Post by Andrew Martin
out of base and into its own library. This doesn't really belong
in
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
base.
Post by Andrew Martin
The interface it provides it somewhat opinionated, and it's not
even
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
Post by Andrew Martin
type-safe. The new library could be named `printf` and could live
under the
Post by Andrew Martin
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
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
ver bumps in recent times, nor is it likely to. So I don't see much
of
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
a
compelling benefit in doing so. The effect I'd expect if we do this
is
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
that `Text.Printf` will be reached for less (which some might argue
to
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
be a desirable effect -- but you're effectively pushing this API to
a
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
path of slow legacy death due to reduced discoverability, IMO), as
the
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
convenience of using it is reduced by requiring adding and
maintaining
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
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
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
Post by Andrew Martin
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing
mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Post by Edward Kmett
Post by Daniel Cartwright
Post by Carter Schonwald
Post by Vanessa McHale
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Edward Kmett
2018-10-29 23:11:30 UTC
Reply
Permalink
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
Post by Daniel Cartwright
Could someone articulate on this "split base"? What does this mean
exactly? Having one or more versions of officially supported 'base'-like
libraries?
Post by Edward Kmett
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 <
Post by 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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Loading...