I guess my main point is that this mailing list reflects and via predating clc, defines what clc is for. And rather than scope creep a single responsibility, articulating that need and facilitating is as a distinct entity is valuable. My idea with HAT is like a modern volunteer organizing touch point of Ye olde Haskell janitors, with each year some different set of folks who were active the previous year as new leadership/organizing touch points for helping facilitate active contributors the subsequent year. Designing for churn to stay fresh as a different take than how we’ve done many of these entity’s for Haskell. Actual Maintainer-ship responsibility should not be via Hat (at least as I envision it), though supporting and empowering active contributors may happily result in some of them being contrib i/ comaintainer. Equally important: library maintainers being responsive about bug fixes is important. Just as important is allowing them agency to evolve the Libs they maintain. I do worry that some Libs that fall under clc atm / as of the spring are likely to never have serious evolution / improvement. But that’s a different issue. On Thu, Feb 11, 2021 at 7:13 PM Carter Schonwald wrote:

These are good points

I think this is actually 3-5 points:

CLC related 1) clc authority is strictly about leadership for helping make design decisions for base the package

2) clc is meant to be a fallback to ensure that there’s backup continuity for maintainership of ghc boot libraries and a design aid for Haskell library authors who are the current maintainers.

But as long as the current maintainership is reachable for communication, the maintainer has final authority. — the clc violated this in spring 2020, while there were car burnings in the neighborhood of the maintainer in question . Bad taste.

3) peripherically clc via base maintainership is the design authority for the library section of the Haskell standard.

—- point being: if you’re not contributing to design decisions for base. you shouldn’t be on the clc. If you are, then you should perhaps be on clc. The current makeup of the clc does not reflect that.

— further more , growing clc should be a reflection of contributors being recognized for their design/hackery contribs

HAT related 4) the idea/goal of hat: empowering and supporting active contributors while not saddling them with official commitments. Rather, HAT is about somone (myself initially), acting as a shield to support current active contributors to enable them to act with greater confidence. I like to think I helped enable that with some of the folks emily mentioned, especially Simon jakobi, viktor and Andrew L.

On Thu, Feb 11, 2021 at 6:54 PM Emily Pillmore wrote:

...

Hi All,

Over the past year, two things have become increasingly clear to me as I've carried out my CLC duties:

1. The CLC is under-resourced. This is evidenced by the fact that several maintainers who are not CLC members have been forced to step up to help take on some of the maintenance burden for many of the CLC libraries. Namely, `vector`, `bytestring`, `random`, `unix`, and more. The current CLC head count is not enough to dedicate at least one maintainer per package, which is leading to us all being spread thin, and the less-loved packages are falling into disrepair as a result. Couple this with the fact that roughly half the CLC do not have these packages actively within their maintenance cycles, and we arrive at the current problem.

2. The current set of "core" libraries does not cover what is generally considered "core" in the community. From now on, I'll refer to "core" packages as "boot" packages, and identify core packages to be those that are have proven to be incredibly popular tools for building things in Haskell. For example `zlib`, `parsec`, `regex-base`, `regex-posix`, `network`, etc. In particular, if any of these core packages saw their current authors disappear, or incapacitated in any sense, it would seriously harm the Haskell ecosystem. `cabal-install`, for example, requires several of those packages as upstream dependencies. Currently, we are dealing with this nightmare situation where work is stalled across many packages due to a particular set of maintainers being very difficult to reach, one of whom having disappeared completely for all maintenance intents and purposes.

Ergo, we have a problem. Thankfully, many people have stepped up showing renewed interest in maintaining such packages with the latest crop of CLC folks, and this poses an interesting opportunity.

My proposal is this:

1. We expand the CLC from 9 members to 22 members such that we have at least 1 CLC maintainer per boot package. There are a large number of fantastic candidates already available, who would be perfect for the role. In fact, many of the candidates whom we would ask are already maintaining these packages. In particular, Andrew Lelechenko, Simon Jakobi, Viktor Dukhovni, Dominic Steinitz, Alexey Khuedyakov are already serving within this role (and thank you for it!). Andreas Abel has also offered to help take on one of the core packages.

2. We consider a dedicated "Haskell Action Team" (name and idea courtesy of Carter Schonwald) to oversee packages in the Haskell github repo that can act as supplementary maintainers for many of the core packages contained therein. Currently, there are many in need of help. `zlib` comes to mind, which is currently blocking `bytestring-0.11` migration work due to having no available maintainer with the permissions to do a release. This, in turn, is stalling `cabal-install`. Short of taking over the package, we would have to ask for an emergency Hackage release if the neither maintainer shows up to do it in a reasonable time frame.

This is just one step towards helping ease the burden of maintenance of so-called core and boot packages. I hope you agree that this is a good idea, and if we get enough thumbs up, then Chessai and I will draw up the necessary changes to the CLC remit and we'll get started!

Cheers, Emily

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

Yeah I strongly agree with the sentiments here, and the concrete measures. Thank you, Emily, for proposing them. I assume some people will be worried about undermining the prerogative of individual maintainers. My view is this *not* a good reason to "hold the CLC back". A bit off topic, but In the long term, I am optimistic for technical solutions to make dealing with libraries and versions, alternative ecosystems, etc. easier. Basically I want it all---both collaborative ownership and authorship, and healthy decentralized experimentation---and I think that's possible. John On 2/12/21 1:46 AM, Julian Ospald wrote:

Hi,

my opinion is that we should develop a zero tolerance towards unresponsive maintainership.

Contributors shouldn't have to escalate on the ML and shouldn't have to request package takeovers. These things are awkward and require more dedication than necessary to be a valuable co-maintainer.

The CLC should proactively scan for popular packages that require new maintainer juice, contact the current maintainers and call for help on the ML (whether core/boot/something-else doesn't really matter to me... redefine the CLC competencies if you must).

I've had many PRs over the years that took 6-12 months for a response. This is not an acceptable response time.

Cheers, Julian

On February 11, 2021 11:54:19 PM UTC, Emily Pillmore wrote:

Hi All,

Over the past year, two things have become increasingly clear to me as I've carried out my CLC duties:

1. The CLC is under-resourced. This is evidenced by the fact that several maintainers who are not CLC members have been forced to step up to help take on some of the maintenance burden for many of the CLC libraries. Namely, `vector`, `bytestring`, `random`, `unix`, and more. The current CLC head count is not enough to dedicate at least one maintainer per package, which is leading to us all being spread thin, and the less-loved packages are falling into disrepair as a result. Couple this with the fact that roughly half the CLC do not have these packages actively within their maintenance cycles, and we arrive at the current problem.

2. The current set of "core" libraries does not cover what is generally considered "core" in the community. From now on, I'll refer to "core" packages as "boot" packages, and identify core packages to be those that are have proven to be incredibly popular tools for building things in Haskell. For example `zlib`, `parsec`, `regex-base`, `regex-posix`, `network`, etc. In particular, if any of these core packages saw their current authors disappear, or incapacitated in any sense, it would seriously harm the Haskell ecosystem. `cabal-install`, for example, requires several of those packages as upstream dependencies. Currently, we are dealing with this nightmare situation where work is stalled across many packages due to a particular set of maintainers being very difficult to reach, one of whom having disappeared completely for all maintenance intents and purposes.

Ergo, we have a problem. Thankfully, many people have stepped up showing renewed interest in maintaining such packages with the latest crop of CLC folks, and this poses an interesting opportunity.

My proposal is this:

1. We expand the CLC from 9 members to 22 members such that we have at least 1 CLC maintainer per boot package. There are a large number of fantastic candidates already available, who would be perfect for the role. In fact, many of the candidates whom we would ask are already maintaining these packages. In particular, Andrew Lelechenko, Simon Jakobi, Viktor Dukhovni, Dominic Steinitz, Alexey Khuedyakov are already serving within this role (and thank you for it!). Andreas Abel has also offered to help take on one of the core packages.

2. We consider a dedicated "Haskell Action Team" (name and idea courtesy of Carter Schonwald) to oversee packages in the Haskell github repo that can act as supplementary maintainers for many of the core packages contained therein. Currently, there are many in need of help. `zlib` comes to mind, which is currently blocking `bytestring-0.11` migration work due to having no available maintainer with the permissions to do a release. This, in turn, is stalling `cabal-install`. Short of taking over the package, we would have to ask for an emergency Hackage release if the neither maintainer shows up to do it in a reasonable time frame.

This is just one step towards helping ease the burden of maintenance of so-called core and boot packages. I hope you agree that this is a good idea, and if we get enough thumbs up, then Chessai and I will draw up the necessary changes to the CLC remit and we'll get started!

Cheers, Emily

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

I agree with your articulated long term goal points, I just worry that we’re not investing in the right structures of organization to support that. I’m more than happy to be wrong though On Sat, Feb 13, 2021 at 3:03 PM John Ericson wrote:

Yeah I strongly agree with the sentiments here, and the concrete measures. Thank you, Emily, for proposing them.

I assume some people will be worried about undermining the prerogative of individual maintainers. My view is this *not* a good reason to "hold the CLC back". A bit off topic, but In the long term, I am optimistic for technical solutions to make dealing with libraries and versions, alternative ecosystems, etc. easier. Basically I want it all---both collaborative ownership and authorship, and healthy decentralized experimentation---and I think that's possible.

John On 2/12/21 1:46 AM, Julian Ospald wrote:

Hi,

my opinion is that we should develop a zero tolerance towards unresponsive maintainership.

Contributors shouldn't have to escalate on the ML and shouldn't have to request package takeovers. These things are awkward and require more dedication than necessary to be a valuable co-maintainer.

The CLC should proactively scan for popular packages that require new maintainer juice, contact the current maintainers and call for help on the ML (whether core/boot/something-else doesn't really matter to me... redefine the CLC competencies if you must).

I've had many PRs over the years that took 6-12 months for a response. This is not an acceptable response time.

Cheers, Julian

On February 11, 2021 11:54:19 PM UTC, Emily Pillmore wrote:

...

Hi All,

Over the past year, two things have become increasingly clear to me as I've carried out my CLC duties:

1. The CLC is under-resourced. This is evidenced by the fact that several maintainers who are not CLC members have been forced to step up to help take on some of the maintenance burden for many of the CLC libraries. Namely, `vector`, `bytestring`, `random`, `unix`, and more. The current CLC head count is not enough to dedicate at least one maintainer per package, which is leading to us all being spread thin, and the less-loved packages are falling into disrepair as a result. Couple this with the fact that roughly half the CLC do not have these packages actively within their maintenance cycles, and we arrive at the current problem.

2. The current set of "core" libraries does not cover what is generally considered "core" in the community. From now on, I'll refer to "core" packages as "boot" packages, and identify core packages to be those that are have proven to be incredibly popular tools for building things in Haskell. For example `zlib`, `parsec`, `regex-base`, `regex-posix`, `network`, etc. In particular, if any of these core packages saw their current authors disappear, or incapacitated in any sense, it would seriously harm the Haskell ecosystem. `cabal-install`, for example, requires several of those packages as upstream dependencies. Currently, we are dealing with this nightmare situation where work is stalled across many packages due to a particular set of maintainers being very difficult to reach, one of whom having disappeared completely for all maintenance intents and purposes.

Ergo, we have a problem. Thankfully, many people have stepped up showing renewed interest in maintaining such packages with the latest crop of CLC folks, and this poses an interesting opportunity.

My proposal is this:

1. We expand the CLC from 9 members to 22 members such that we have at least 1 CLC maintainer per boot package. There are a large number of fantastic candidates already available, who would be perfect for the role. In fact, many of the candidates whom we would ask are already maintaining these packages. In particular, Andrew Lelechenko, Simon Jakobi, Viktor Dukhovni, Dominic Steinitz, Alexey Khuedyakov are already serving within this role (and thank you for it!). Andreas Abel has also offered to help take on one of the core packages.

2. We consider a dedicated "Haskell Action Team" (name and idea courtesy of Carter Schonwald) to oversee packages in the Haskell github repo that can act as supplementary maintainers for many of the core packages contained therein. Currently, there are many in need of help. `zlib` comes to mind, which is currently blocking `bytestring-0.11` migration work due to having no available maintainer with the permissions to do a release. This, in turn, is stalling `cabal-install`. Short of taking over the package, we would have to ask for an emergency Hackage release if the neither maintainer shows up to do it in a reasonable time frame.

This is just one step towards helping ease the burden of maintenance of so-called core and boot packages. I hope you agree that this is a good idea, and if we get enough thumbs up, then Chessai and I will draw up the necessary changes to the CLC remit and we'll get started!

Cheers, Emily

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

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

I would be happy for the CLC to expand, assuming that qualified candidates step forward. Twenty-two seems rather optimistic to me, since we typically don't see many applicants. Perhaps it can be an aspirational goal. Regarding a "Haskell Action Team", I definitely think more maintainers on some core libraries and more active members of the Haskell github organisation would help, but I'm not sure we really need another named volunteer organisation established within Haskell. Between the CLC, the Hackage trustees, the Haskell.org Committee, the GHC Steering Committee, the Haskell Prime Committee (if it gets going again), and now the Foundation, we really do have a lot of those already. I bet I have even forgotten at least one! To attempt to form this new group, on top of expanding the CLC to twenty-two, would surely involve a significant overlap between the groups. Otherwise you'd have to conjure a lot more trusted, highly-advanced Haskellers with free time than I think exist. Cheers, George On Tue, 16 Feb 2021 at 04:11, John Ericson wrote:

Carter,

It's not exactly clear to me where your two proposals differ? It seems like Emily said "bigger CLC" with HAT, while you are saying a separate org, perhaps with the CLC inside the HAT? I'm guessing the idea there is to make the degree of control inversely vary with the number of libraries in the purview?

...

I do worry that some Libs that fall under clc atm / as of the spring are likely to never have serious evolution / improvement. But that’s a different issue.

Yes I would like to get into that at some point too. (Pithily put, my view is chop up each library until its contents are uncontroversial.) This is what makes me less concerned about the difference between a bigger CLC and rings of orgs.

John On 2/13/21 7:01 PM, Carter Schonwald wrote:

I agree with your articulated long term goal points, I just worry that we’re not investing in the right structures of organization to support that. I’m more than happy to be wrong though

On Sat, Feb 13, 2021 at 3:03 PM John Ericson wrote:

...

Yeah I strongly agree with the sentiments here, and the concrete measures. Thank you, Emily, for proposing them.

I assume some people will be worried about undermining the prerogative of individual maintainers. My view is this *not* a good reason to "hold the CLC back". A bit off topic, but In the long term, I am optimistic for technical solutions to make dealing with libraries and versions, alternative ecosystems, etc. easier. Basically I want it all---both collaborative ownership and authorship, and healthy decentralized experimentation---and I think that's possible.

John On 2/12/21 1:46 AM, Julian Ospald wrote:

Hi,

my opinion is that we should develop a zero tolerance towards unresponsive maintainership.

Contributors shouldn't have to escalate on the ML and shouldn't have to request package takeovers. These things are awkward and require more dedication than necessary to be a valuable co-maintainer.

The CLC should proactively scan for popular packages that require new maintainer juice, contact the current maintainers and call for help on the ML (whether core/boot/something-else doesn't really matter to me... redefine the CLC competencies if you must).

I've had many PRs over the years that took 6-12 months for a response. This is not an acceptable response time.

Cheers, Julian

On February 11, 2021 11:54:19 PM UTC, Emily Pillmore wrote:

...

Hi All,

Over the past year, two things have become increasingly clear to me as I've carried out my CLC duties:

1. The CLC is under-resourced. This is evidenced by the fact that several maintainers who are not CLC members have been forced to step up to help take on some of the maintenance burden for many of the CLC libraries. Namely, `vector`, `bytestring`, `random`, `unix`, and more. The current CLC head count is not enough to dedicate at least one maintainer per package, which is leading to us all being spread thin, and the less-loved packages are falling into disrepair as a result. Couple this with the fact that roughly half the CLC do not have these packages actively within their maintenance cycles, and we arrive at the current problem.

2. The current set of "core" libraries does not cover what is generally considered "core" in the community. From now on, I'll refer to "core" packages as "boot" packages, and identify core packages to be those that are have proven to be incredibly popular tools for building things in Haskell. For example `zlib`, `parsec`, `regex-base`, `regex-posix`, `network`, etc. In particular, if any of these core packages saw their current authors disappear, or incapacitated in any sense, it would seriously harm the Haskell ecosystem. `cabal-install`, for example, requires several of those packages as upstream dependencies. Currently, we are dealing with this nightmare situation where work is stalled across many packages due to a particular set of maintainers being very difficult to reach, one of whom having disappeared completely for all maintenance intents and purposes.

Ergo, we have a problem. Thankfully, many people have stepped up showing renewed interest in maintaining such packages with the latest crop of CLC folks, and this poses an interesting opportunity.

My proposal is this:

1. We expand the CLC from 9 members to 22 members such that we have at least 1 CLC maintainer per boot package. There are a large number of fantastic candidates already available, who would be perfect for the role. In fact, many of the candidates whom we would ask are already maintaining these packages. In particular, Andrew Lelechenko, Simon Jakobi, Viktor Dukhovni, Dominic Steinitz, Alexey Khuedyakov are already serving within this role (and thank you for it!). Andreas Abel has also offered to help take on one of the core packages.

2. We consider a dedicated "Haskell Action Team" (name and idea courtesy of Carter Schonwald) to oversee packages in the Haskell github repo that can act as supplementary maintainers for many of the core packages contained therein. Currently, there are many in need of help. `zlib` comes to mind, which is currently blocking `bytestring-0.11` migration work due to having no available maintainer with the permissions to do a release. This, in turn, is stalling `cabal-install`. Short of taking over the package, we would have to ask for an emergency Hackage release if the neither maintainer shows up to do it in a reasonable time frame.

This is just one step towards helping ease the burden of maintenance of so-called core and boot packages. I hope you agree that this is a good idea, and if we get enough thumbs up, then Chessai and I will draw up the necessary changes to the CLC remit and we'll get started!

Cheers, Emily

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

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

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

Carter's words touched me. Ever neither smart nor silent, I am going to be a little loud once more. Being an outside spectator of this venue, a beneficiary _(one of innumerably many)_ of the work being inconspicuously done by the persons present, and a skilled developer that potentially may shoulder some of the burden, I would really like to understand better the structure of power and the philosophy behind the CLC enterprise — it is not observable, therefore I cannot decide who to be thankful to and whether my participation is reasonably warranted. I know there are people that do a huge amount of work continuously fixing a vaguely defined cloud of _«core»_ packages — but I also know these people have no idea that I exist, from which it follows that my needs and wishes are respected only accidentally. I am voicing this thought for these reasons: * I am a small scale commercial Haskell user — on its face it classifies me as the target audience. I am invested into Haskell but not a luminary like those others present here — rather an ordinary person, an average. In some way this makes me a representative example. * I am somewhat altruistic. I contribute open source code, answer questions about Haskell and even help people privately without mercantile aims. This suggests that I should want to participate in an effort that is beneficial to many — being an altruist, I may as well be an effective one. If there is a person that should be caught in the wave, that is me here. But it is very evident that I am not. The story is that I asked `\x → (x, x)` to be given a place in standard libraries — hard to find a more innocent proposition. As some know, it did not go well. _(This is not an only example but the most striking.)_ There are several possible explanations. 1. This is meritocracy at work. Haskell collects some of the most gifted programmers of the world. A mere mortal cannot possibly suggest any beneficial change to `base` or `containers` or `vector` or `cabal-install` — in all likelihood it was already considered by the wise council. 2. The philosophy is unclear and undisputed. For example, it was suggested to me in private correspondence that the reason the standard libraries are not being extended more often is because exporting more names is wrong. This is of course as valid a principle as any — but I do not see it being spelled out and considered on the basis of evidence. Perhaps the wizards of code are not that good at other things, like being clear about their design goals. 3. The power structure is set up in favour of a specific invisible group that sets the tune. Recall the story about Stack and Cabal. It had been shown clearly that the interests of the community at large are not represented in the group of maintainers of Cabal. It is hard to triangulate from the distance what exactly went wrong, but on the basis of the meager evidence that I can have, the theory is plausible, and evidence keeps adding up. There is also a question of who selects the libraries to be called _«core»_. For example, Stack _(and, consequently, half the user base of Haskell)_ depends on `rio`, and `typed-process` is a superiour replacement for `process`. Should the _«core»_ include packages vital to half the user base? Should it include a superiour replacement of a morally obsolete package? Or is it a place where leviathans of the past come to die? What does it entail for a package to be considered _«core»_? Does it get included in the standard distribution? What sort of packages should we like to distribute? Finally, there is a question of high principles. Haskell can be a pragmatic tool of the trade or a paragon of elegance, rock-solid or bleeding edge… maybe even all of it at once, but what does the _management_ want it to be? What do you folks dream of? What is your ideal? I cannot see any — I only see reactive efforts to fend off the inevitably approaching future. No one would be inspired by that. I suspect there are a few people that get paid to contribute to Haskell. Maybe that should be the main motive instead? Maybe it is time to say that Haskell is a commercial language maintained by corporate employees? I would not like to be one but at least expectations would be aligned. Haskell has not only made me a programmer — it defined me as a person. There is no other language and no other community like this one. I have reverence. Is it the same for anyone else here? Or should I, rather, grow up and move on?

I second Simon's words. I didn't read the previous thread, nor will I, so I have no idea what happened with your suggestion. The Haskell Foundation is primed to work toward solving some of the problems with the standard library. FWIW, your suggested operation is a primitive operation of the Extend/Comonad type-class called duplicate, though this is not in the standard libraries. On 2/17/21 8:54 AM, Simon Peyton Jones via Libraries wrote:

Ignat

Thanks for writing. You are just the sort of person that ought to feel welcome, and able to contribute. That you have not felt that way is a failure.

I'd like to suggest another explanation to the three you offer (none of which I subscribe to).

4. The now-very-large Haskell ecosystem runs on the efforts of busy volunteers, all of whom have day jobs. However well-meaning or high-minded we are, things will be left undone, or done less well than we aspire to.

I hope and believe that the Haskell Foundation will help with this challenge. I don’t think it'll be a silver bullet. But it should help; and making volunteers such as you feel both welcome and able to contribute meaningfully is certainly a major goal.

| Haskell has not only made me a programmer — it defined me as a person.  | There is no other language and no other community like this one. I have | reverence. Is it the same for anyone else here? Or should I, rather, grow | up and move on?

Please don't grow up and move on! We are working together to build not just a language to be proud of, but a community we can flourish in. We will stumble for sure, but if we are humble, respectful of each other, and willing to keep trying, I think we can succeed.

Simon

| -----Original Message----- | From: Libraries On Behalf Of Ignat | Insarov | Sent: 16 February 2021 21:57 | To: Carter Schonwald | Cc: Haskell Libraries | Subject: Re: Proposal: Expanding the CLC | | Carter's words touched me. Ever neither smart nor silent, I am going to | be a little loud once more. | | Being an outside spectator of this venue, a beneficiary _(one of | innumerably many)_ of the work being inconspicuously done by the persons | present, and a skilled developer that potentially may shoulder some of | the burden, I would really like to understand better the structure of | power and the philosophy behind the CLC enterprise — it is not | observable, therefore I cannot decide who to be thankful to and whether | my participation is reasonably warranted. I know there are people that do | a huge amount of work continuously fixing a vaguely defined cloud of | _«core»_ packages — but I also know these people have no idea that I | exist, from which it follows that my needs and wishes are respected only | accidentally. | | I am voicing this thought for these reasons: | | * I am a small scale commercial Haskell user — on its face it classifies | me as | the target audience. I am invested into Haskell but not a luminary like | those | others present here — rather an ordinary person, an average. In some | way this | makes me a representative example. | | * I am somewhat altruistic. I contribute open source code, answer | questions | about Haskell and even help people privately without mercantile aims.  | This | suggests that I should want to participate in an effort that is | beneficial to | many — being an altruist, I may as well be an effective one. | | If there is a person that should be caught in the wave, that is me here.  | But it is very evident that I am not. The story is that I asked `\x → (x, | x)` to be given a place in standard libraries — hard to find a more | innocent proposition. As some know, it did not go well. _(This is not an | only example but the most striking.)_ There are several possible | explanations. | | 1. This is meritocracy at work. Haskell collects some of the most gifted | programmers of the world. A mere mortal cannot possibly suggest any | beneficial change to `base` or `containers` or `vector` or `cabal- | install` — | in all likelihood it was already considered by the wise council. | | 2. The philosophy is unclear and undisputed. For example, it was | suggested to me | in private correspondence that the reason the standard libraries are | not | being extended more often is because exporting more names is wrong.  | This is | of course as valid a principle as any — but I do not see it being | spelled out | and considered on the basis of evidence. Perhaps the wizards of code | are not | that good at other things, like being clear about their design goals. | | 3. The power structure is set up in favour of a specific invisible group | that | sets the tune. Recall the story about Stack and Cabal. It had been | shown | clearly that the interests of the community at large are not | represented in | the group of maintainers of Cabal. It is hard to triangulate from the | distance what exactly went wrong, but on the basis of the meager | evidence | that I can have, the theory is plausible, and evidence keeps adding | up. | | There is also a question of who selects the libraries to be called | _«core»_. For example, Stack _(and, consequently, half the user base of | Haskell)_ depends on `rio`, and `typed-process` is a superiour | replacement for `process`. Should the _«core»_ include packages vital to | half the user base? Should it include a superiour replacement of a | morally obsolete package? Or is it a place where leviathans of the past | come to die? What does it entail for a package to be considered _«core»_?  | Does it get included in the standard distribution? What sort of packages | should we like to distribute? | | Finally, there is a question of high principles. Haskell can be a | pragmatic tool of the trade or a paragon of elegance, rock-solid or | bleeding edge… maybe even all of it at once, but what does the | _management_ want it to be? What do you folks dream of? What is your | ideal? I cannot see any — I only see reactive efforts to fend off the | inevitably approaching future. No one would be inspired by that. I | suspect there are a few people that get paid to contribute to Haskell.  | Maybe that should be the main motive instead? Maybe it is time to say | that Haskell is a commercial language maintained by corporate employees?  | I would not like to be one but at least expectations would be aligned. | | Haskell has not only made me a programmer — it defined me as a person.  | There is no other language and no other community like this one. I have | reverence. Is it the same for anyone else here? Or should I, rather, grow | up and move on? | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.has | kell.org%2Fcgi- | bin%2Fmailman%2Flistinfo%2Flibraries&data=04%7C01%7Csimonpj%40microso | ft.com%7C7f7bb62c42ac43639d6a08d8d2c5c706%7C72f988bf86f141af91ab2d7cd011d | b47%7C1%7C0%7C637491094192227676%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw | MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VxR73 | 6V5TUUf%2B0OfzlBAQK9GG1CpaiBZahvqtiE7obM%3D&reserved=0 _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries