From emilypi at cohomolo.gy Tue Aug 10 21:01:22 2021 From: emilypi at cohomolo.gy (Emily Pillmore) Date: Tue, 10 Aug 2021 21:01:22 +0000 Subject: State of the CLC Message-ID: Hello Haskell! The Core Libraries Committee is undergoing some changes at the moment, and I'd like to fill everyone in about the state of the CLC, what's happening behind the scenes, and what we hope to accomplish in the future. It's no secret that the CLC hasn't been as active as of late, and hopefully this post will serve to clear that up and invite new interest in our plans going forward. ## History of the CLC Originally, the CLC was created to steward the `base` library and review changes to it, which no one was really empowered to do before its inception. In particular, this was extremely helpful in stewarding large changesets such as the FTP and AMP proposals. With the success of these proposal implementations, the responsibilities and headcount of the CLC grew to the point where they were asked to steward not just `base`, but also a collection of "mission critical" libraries that GHC relied upon in order to function. Slowly, the number of these packages grew to 13 including `base`. The previous authors and maintainers of the core libraries slowly exited the community for various reasons, and due to lack of ability to find new maintainers, responsibility devolved to the CLC taking control. The CLC, however, did not grow along with it. CLC members viewed these packages as stable, and therefore not in need of consistent code-changes modulo a version bump here and there, or the odd update for new GHC features. ## CLC as of Today Today , we realize that the perception of a stable set of core libraries is not true to reality. In fact, this was realized about the time I joined in 2019, but it had not quite sunk in: our core libraries are in need of constant maintenance. In fact, many of the core libraries we do have are not stable because they are in a stable, performant and well-maintained state, but are stable because nothing has been done with them. It is a dire error that the two were confused. In many cases, we were the ones blocking the changes! This is not to say that each of the core libraries suffers, but many do, and this is a problem. For example, recently orders of magnitude changes in performance and usability came in the form of pull requests to `random` and `bytestring`, where before they were considered to be completely stable. In the case of `random`, a CLC member stood in the way of that progress. In the case of other libraries, progress stalled because the CLC was not equipped to maintain the libraries it was charged with stewarding, and new maintainers could not be found. However, this is not to heap blame on anyone in particular. The creeping expansion of our responsibilities on the CLC caused two major problems: 1. We had too many responsibilities, and scope kept creeping. What started out as `base` turned into `base` and stewarding core libraries. Stewarding the core libraries turned into maintaining the core libraries. Maintaining turned into architecting new feature changes etc. 2. Despite life generally being balanced with CLC duties, the last few years have also added the weight of a general malaise of stress induced by our respective sociopolitical and economic climates. As a result, despite being 8-strong on paper, the CLC has actually been operating with only 2.5 active people since 2019 (the .5 coming from 2 sporadically active CLC members). This is not enough to keep up with the general workload, nor enough to decide quorum. Behind the scenes, we've been feeling this pressure and working with it since the COVID-19 pandemic started, but at this point in time, we're looking to disband the current iteration of the CLC and work towards a new structure that will be more maintainable in the future. ## CLC in the Future Three weeks ago, I sent out [an email]( https://hackmd.io/rSBGz4bgRgq5w-tUH_m68w ) to the CLC asking for a role call, advertising the will to restructure. With some gentle prodding, we have 3 members who raised their hand (Chessai, myself, and gwils), and 1 who will help us rebuild and reassess their involvement pending the outcome (Cale Gibbard). The 4 of us will meet on Thursday of next week to discuss a restructuring of our responsibilities and what to do moving forward. I expect that the structure of the CLC will scale back to maintaining `base` as a main focus, with a new proposal process in the vein of the Haskell Foundation or GHC tech proposals process, and the designation of new roles to help shepherd issues to us and manage contributors. This will effectively be reasserting the CLC's original mission statement, with some better process for onboarding community-led contributions to `base`, and a clearer notion of what it means to maintain core libraries. Then, finding new maintainers for some of the core libraries will be the final hurdle for the new CLC. I think this is a very necessary change that is possibly 5 years too late, but c'est la vie. I'm happy that the CLC are amenable to this change, and I hope that we see alot of very fruitful discussion amongst the community on how best to structure in a way that meets your demands more effectively. I'm putting a time box on a finished process by mid to late September (give us a month+ to sort it out), and we'll be back and more effective than ever. Also, since the email sent out served as a means of figuring out which members were actively, we will be adding as many or more CLC members to help move things forward. Cheers, and I hope this gives enough detail for everyone. Emily -------------- next part -------------- An HTML attachment was scrubbed... URL: From hasufell at posteo.de Wed Aug 11 05:52:12 2021 From: hasufell at posteo.de (Julian Ospald) Date: Wed, 11 Aug 2021 05:52:12 +0000 Subject: State of the CLC In-Reply-To: References: Message-ID: On August 10, 2021 9:01:22 PM UTC, Emily Pillmore wrote: > >I expect that the structure of the CLC will scale back to maintaining `base` as a main focus, with a new proposal process in the vein of the Haskell Foundation or GHC tech proposals process, and the designation of new roles to help shepherd issues to us and manage contributors. Can you be more precise here? Is it simply about creating a contribution process (which already exists afaik, it's just that you barely get any response for core libraries) or is the idea to run part of the contribution pipeline through the HF? From emilypi at cohomolo.gy Wed Aug 11 23:15:59 2021 From: emilypi at cohomolo.gy (Emily Pillmore) Date: Wed, 11 Aug 2021 23:15:59 +0000 Subject: State of the CLC In-Reply-To: References: Message-ID: You really know how to get right to the heart of where I'm being intentionally vague and asking questions about it! :) I can speak a little bit to your questions, but the technical details of the proposal were intentionally left out because we simply haven't convened to discuss anything in concretions yet. However, I can give you my thoughts on where I'd like to take this, personally: > > Is it simply about creating a contribution process (which already exists > afaik, it's just that you barely get any response for core libraries) > > A contribution process is one part of it, and it's a little more complicated than the situation you describe. Mainly, yes, a contribution process exists and the CLC has been historically poor at answering the call. However, this is not simply because the CLC has been derelict - my contention is that it was never very efficient, and has simply been completely defunct for some time now. Here are some thoughts I have on the matter off the top of my head for how we can improve things: * I feel (as do others in the CLC and outside of it) that the mailing list is good for some contributions, but poor for others. Namely, some contributions to base are small enough that they should occur as a pull request against `base`, a ping to the CLC, and we should review it without getting everyone who monitors this list involved. Historically, contributions that are small in scope, and possibly trivial quality of life contributions are defeated by bikeshedding. Too many cooks is a very real phenomenon in this mailing list. We would like to make sure that the process for deciding where to submit an idea is well documented, and that it is a separate avenue. * For mid-sized contributions, the mailing list is great! However, there does seem to be a culture, particularly in this list of not being oriented towards solutions. There is not enough skin in the game. I get the impression in many cases (and others have expressed similar complaints) that  many interactions are simply "gotcha"-style intellectual mounting games instead of solution finding, and this causes alot of frustration consistently enough for people to voice the complaint to me. * For larger contributions, like the Abstract file path proposal, I think a mailing list is perhaps too small a forum to discuss it, and it would be better served by a GHC proposal-style process that is more open for comment, searchable, and and history not so scattered. Further, without a project manager for larger contributions, these things get lost easily, and we would like to solve that by adding a role, and reworking the process for larger, overarching changes to `base`. * Mailing lists are generally not friendly to searches, history, or finding out who's in charge of what. In addition to this, what I have in mind is to add more members to the CLC, to allow for a more fluid process for onboarding and offboarding CLC members as they become or fall out of availability. I would also like to lower the bar, as you suggested on Reddit might be a good idea. I don't think requiring galaxy brains is the right tack we need to take. I would rather have productive engineers who can bring new ideas to the table about how to improve the state of `base`. > > contribution pipeline through the HF? > > This is not in our plans, though, we have spoken a little bit about whether or not someone from the HF could serve as a shepherd for issues and CLC member wrangler. However, I don't think this would be in any official HF capacity as much as it would be a good will gesture. Mainly though, a project manager is in our interests, be it an HF person or not. Cheers, Emily On Tue, Aug 10, 2021 at 11:52 PM, Julian Ospald < hasufell at posteo.de > wrote: > > > > On August 10, 2021 9:01:22 PM UTC, Emily Pillmore < emilypi@ cohomolo. gy ( > emilypi at cohomolo.gy ) > wrote: > > >> >> >> I expect that the structure of the CLC will scale back to maintaining >> `base` as a main focus, with a new proposal process in the vein of the >> Haskell Foundation or GHC tech proposals process, and the designation of >> new roles to help shepherd issues to us and manage contributors. >> >> > > > > Can you be more precise here? Is it simply about creating a contribution > process (which already exists afaik, it's just that you barely get any > response for core libraries) or is the idea to run part of the > contribution pipeline through the HF? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Aug 12 08:00:30 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 12 Aug 2021 08:00:30 +0000 Subject: State of the CLC In-Reply-To: References: Message-ID: I’d like to suggest that a mailing list isn’t good even for mis-sized contributions. One of the difficulties of managing the CLC process is that it often consists of a number of small proposals, all in flight. It’s very easy for them to get lost and – especially because they are small – that is very frustrating for the contributor. I think it would help to have mechanical support of some kind, that makes it easy to answer questions like * What proposed changes to `base` and `ghc-prim` are in flight? (No matter how small!) * Which of those changes are in “open-discussion” mode (relaxed timescale), and which have been submitted to the committee for decision (fixed timescale). For the latter, on what date was the proposal submitted? * What decisions has the committee taken? To accept, or reject, or push-back a proposal? A mailing list is poorly adapted to answering these questions. But I think much frustration arises not because anyone is being lazy or negligent, but simply because volunteers are busy, and it’s hard to keep multiple threads going in your head and all too easy for them to drift – sometimes for ever. It’s almost more important to do this to keep track of the many small proposals than for the few big ones. Using PRs is one sort of mechanical support, provided there is some kind of tagging giving the status (in-discussion, under-committee-review, accepted, rejected) of each. I’m not directly involved in CLC, so these are just suggestions. Simon From: Libraries On Behalf Of Emily Pillmore Sent: 12 August 2021 00:16 To: Julian Ospald Cc: libraries at haskell.org Subject: Re: State of the CLC You really know how to get right to the heart of where I'm being intentionally vague and asking questions about it! :) I can speak a little bit to your questions, but the technical details of the proposal were intentionally left out because we simply haven't convened to discuss anything in concretions yet. However, I can give you my thoughts on where I'd like to take this, personally: Is it simply about creating a contribution process (which already exists afaik, it's just that you barely get any response for core libraries) A contribution process is one part of it, and it's a little more complicated than the situation you describe. Mainly, yes, a contribution process exists and the CLC has been historically poor at answering the call. However, this is not simply because the CLC has been derelict - my contention is that it was never very efficient, and has simply been completely defunct for some time now. Here are some thoughts I have on the matter off the top of my head for how we can improve things: 1. I feel (as do others in the CLC and outside of it) that the mailing list is good for some contributions, but poor for others. Namely, some contributions to base are small enough that they should occur as a pull request against `base`, a ping to the CLC, and we should review it without getting everyone who monitors this list involved. Historically, contributions that are small in scope, and possibly trivial quality of life contributions are defeated by bikeshedding. Too many cooks is a very real phenomenon in this mailing list. We would like to make sure that the process for deciding where to submit an idea is well documented, and that it is a separate avenue. 2. For mid-sized contributions, the mailing list is great! However, there does seem to be a culture, particularly in this list of not being oriented towards solutions. There is not enough skin in the game. I get the impression in many cases (and others have expressed similar complaints) that many interactions are simply "gotcha"-style intellectual mounting games instead of solution finding, and this causes alot of frustration consistently enough for people to voice the complaint to me. 3. For larger contributions, like the Abstract file path proposal, I think a mailing list is perhaps too small a forum to discuss it, and it would be better served by a GHC proposal-style process that is more open for comment, searchable, and and history not so scattered. Further, without a project manager for larger contributions, these things get lost easily, and we would like to solve that by adding a role, and reworking the process for larger, overarching changes to `base`. 4. Mailing lists are generally not friendly to searches, history, or finding out who's in charge of what. In addition to this, what I have in mind is to add more members to the CLC, to allow for a more fluid process for onboarding and offboarding CLC members as they become or fall out of availability. I would also like to lower the bar, as you suggested on Reddit might be a good idea. I don't think requiring galaxy brains is the right tack we need to take. I would rather have productive engineers who can bring new ideas to the table about how to improve the state of `base`. contribution pipeline through the HF? This is not in our plans, though, we have spoken a little bit about whether or not someone from the HF could serve as a shepherd for issues and CLC member wrangler. However, I don't think this would be in any official HF capacity as much as it would be a good will gesture. Mainly though, a project manager is in our interests, be it an HF person or not. Cheers, Emily On Tue, Aug 10, 2021 at 11:52 PM, Julian Ospald > wrote: On August 10, 2021 9:01:22 PM UTC, Emily Pillmore > wrote: I expect that the structure of the CLC will scale back to maintaining `base` as a main focus, with a new proposal process in the vein of the Haskell Foundation or GHC tech proposals process, and the designation of new roles to help shepherd issues to us and manage contributors. Can you be more precise here? Is it simply about creating a contribution process (which already exists afaik, it's just that you barely get any response for core libraries) or is the idea to run part of the contribution pipeline through the HF? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hasufell at posteo.de Thu Aug 12 12:49:08 2021 From: hasufell at posteo.de (Julian Ospald) Date: Thu, 12 Aug 2021 12:49:08 +0000 Subject: State of the CLC [wrt MLs] In-Reply-To: References: Message-ID: I'm not sure Simon, many projects larger than the CLC are using mailing lists with much higher throughput: * https://lkml.org/ * https://archives.gentoo.org/gentoo-dev/threads * https://lists.debian.org/ These have done so for decades and had enough time to consider alternatives. To get into more detail: 1. Mails have threads! But one has to use them properly. The subject when creating a reply can be adjusted as well. 2. Cross-posting is very easy. Much easier than jumping between reddit, discourse and github PRs. 3. They can be used for patches and reviews as well and many projects still use this mechanism. You don't even have to use git for that. I'm not advocating for that, but it shows that it's a very simple and powerful communication tool, even today. 4. They are persistent and searchable through ML archives. I believe this just boils down to communication discipline and moderation. In lack of both, I believe no matter the tool, the experience won't be pleasant (issue tracker discussions are worse imo, since they often don't have good threading). Cheers, Julian On August 12, 2021 8:00:30 AM UTC, Simon Peyton Jones wrote: >I’d like to suggest that a mailing list isn’t good even for mis-sized contributions. > >One of the difficulties of managing the CLC process is that it often consists of a number of small proposals, all in flight. It’s very easy for them to get lost and – especially because they are small – that is very frustrating for the contributor. > >I think it would help to have mechanical support of some kind, that makes it easy to answer questions like > > > * What proposed changes to `base` and `ghc-prim` are in flight? (No matter how small!) > * Which of those changes are in “open-discussion” mode (relaxed timescale), and which have been submitted to the committee for decision (fixed timescale). For the latter, on what date was the proposal submitted? > * What decisions has the committee taken? To accept, or reject, or push-back a proposal? > >A mailing list is poorly adapted to answering these questions. But I think much frustration arises not because anyone is being lazy or negligent, but simply because volunteers are busy, and it’s hard to keep multiple threads going in your head and all too easy for them to drift – sometimes for ever. > >It’s almost more important to do this to keep track of the many small proposals than for the few big ones. > >Using PRs is one sort of mechanical support, provided there is some kind of tagging giving the status (in-discussion, under-committee-review, accepted, rejected) of each. > >I’m not directly involved in CLC, so these are just suggestions. > >Simon > >From: Libraries On Behalf Of Emily Pillmore >Sent: 12 August 2021 00:16 >To: Julian Ospald >Cc: libraries at haskell.org >Subject: Re: State of the CLC > >You really know how to get right to the heart of where I'm being intentionally vague and asking questions about it! :) > >I can speak a little bit to your questions, but the technical details of the proposal were intentionally left out because we simply haven't convened to discuss anything in concretions yet. However, I can give you my thoughts on where I'd like to take this, personally: >Is it simply about creating a contribution process (which already exists afaik, it's just that you barely get any response for core libraries) > >A contribution process is one part of it, and it's a little more complicated than the situation you describe. Mainly, yes, a contribution process exists and the CLC has been historically poor at answering the call. However, this is not simply because the CLC has been derelict - my contention is that it was never very efficient, and has simply been completely defunct for some time now. Here are some thoughts I have on the matter off the top of my head for how we can improve things: > > 1. I feel (as do others in the CLC and outside of it) that the mailing list is good for some contributions, but poor for others. Namely, some contributions to base are small enough that they should occur as a pull request against `base`, a ping to the CLC, and we should review it without getting everyone who monitors this list involved. Historically, contributions that are small in scope, and possibly trivial quality of life contributions are defeated by bikeshedding. Too many cooks is a very real phenomenon in this mailing list. We would like to make sure that the process for deciding where to submit an idea is well documented, and that it is a separate avenue. > 2. For mid-sized contributions, the mailing list is great! However, there does seem to be a culture, particularly in this list of not being oriented towards solutions. There is not enough skin in the game. I get the impression in many cases (and others have expressed similar complaints) that many interactions are simply "gotcha"-style intellectual mounting games instead of solution finding, and this causes alot of frustration consistently enough for people to voice the complaint to me. > 3. For larger contributions, like the Abstract file path proposal, I think a mailing list is perhaps too small a forum to discuss it, and it would be better served by a GHC proposal-style process that is more open for comment, searchable, and and history not so scattered. Further, without a project manager for larger contributions, these things get lost easily, and we would like to solve that by adding a role, and reworking the process for larger, overarching changes to `base`. > 4. Mailing lists are generally not friendly to searches, history, or finding out who's in charge of what. > >In addition to this, what I have in mind is to add more members to the CLC, to allow for a more fluid process for onboarding and offboarding CLC members as they become or fall out of availability. I would also like to lower the bar, as you suggested on Reddit might be a good idea. I don't think requiring galaxy brains is the right tack we need to take. I would rather have productive engineers who can bring new ideas to the table about how to improve the state of `base`. > >contribution pipeline through the HF? > >This is not in our plans, though, we have spoken a little bit about whether or not someone from the HF could serve as a shepherd for issues and CLC member wrangler. However, I don't think this would be in any official HF capacity as much as it would be a good will gesture. Mainly though, a project manager is in our interests, be it an HF person or not. > >Cheers, >Emily > > > > > > > >On Tue, Aug 10, 2021 at 11:52 PM, Julian Ospald > wrote: > >On August 10, 2021 9:01:22 PM UTC, Emily Pillmore > wrote: > >I expect that the structure of the CLC will scale back to maintaining `base` as a main focus, with a new proposal process in the vein of the Haskell Foundation or GHC tech proposals process, and the designation of new roles to help shepherd issues to us and manage contributors. > >Can you be more precise here? Is it simply about creating a contribution process (which already exists afaik, it's just that you barely get any response for core libraries) or is the idea to run part of the contribution pipeline through the HF? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Aug 12 15:20:46 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 12 Aug 2021 15:20:46 +0000 Subject: State of the CLC [wrt MLs] In-Reply-To: References: Message-ID: Fair enough Julian. Any system that allows rapid, unequivocal, and universally-agreed answers to the questions I list below would be fine with me. I don't quite see how email can do that (e.g. press a button to list the proposals under committee review), but if it can, so much the better. Oh, I should add one more: * What exactly is the proposal that the committee has accepted? One should be able to answer that by pointing to a (perhaps short) document or PR. It is much much less good to reply "It's the proposal made in this email, and then modified and fine-tuned by the following 20". Email is good for the process and discussion; it is less good at recording the outcome and decision. Simon From: Julian Ospald Sent: 12 August 2021 13:49 To: Simon Peyton Jones ; Emily Pillmore Cc: libraries at haskell.org Subject: RE: State of the CLC [wrt MLs] I'm not sure Simon, many projects larger than the CLC are using mailing lists with much higher throughput: * https://lkml.org/ * https://archives.gentoo.org/gentoo-dev/threads * https://lists.debian.org/ These have done so for decades and had enough time to consider alternatives. To get into more detail: 1. Mails have threads! But one has to use them properly. The subject when creating a reply can be adjusted as well. 2. Cross-posting is very easy. Much easier than jumping between reddit, discourse and github PRs. 3. They can be used for patches and reviews as well and many projects still use this mechanism. You don't even have to use git for that. I'm not advocating for that, but it shows that it's a very simple and powerful communication tool, even today. 4. They are persistent and searchable through ML archives. I believe this just boils down to communication discipline and moderation. In lack of both, I believe no matter the tool, the experience won't be pleasant (issue tracker discussions are worse imo, since they often don't have good threading). Cheers, Julian On August 12, 2021 8:00:30 AM UTC, Simon Peyton Jones wrote: I'd like to suggest that a mailing list isn't good even for mis-sized contributions. One of the difficulties of managing the CLC process is that it often consists of a number of small proposals, all in flight. It's very easy for them to get lost and - especially because they are small - that is very frustrating for the contributor. I think it would help to have mechanical support of some kind, that makes it easy to answer questions like * What proposed changes to `base` and `ghc-prim` are in flight? (No matter how small!) * Which of those changes are in "open-discussion" mode (relaxed timescale), and which have been submitted to the committee for decision (fixed timescale). For the latter, on what date was the proposal submitted? * What decisions has the committee taken? To accept, or reject, or push-back a proposal? A mailing list is poorly adapted to answering these questions. But I think much frustration arises not because anyone is being lazy or negligent, but simply because volunteers are busy, and it's hard to keep multiple threads going in your head and all too easy for them to drift - sometimes for ever. It's almost more important to do this to keep track of the many small proposals than for the few big ones. Using PRs is one sort of mechanical support, provided there is some kind of tagging giving the status (in-discussion, under-committee-review, accepted, rejected) of each. I'm not directly involved in CLC, so these are just suggestions. Simon From: Libraries On Behalf Of Emily Pillmore Sent: 12 August 2021 00:16 To: Julian Ospald Cc: libraries at haskell.org Subject: Re: State of the CLC You really know how to get right to the heart of where I'm being intentionally vague and asking questions about it! :) I can speak a little bit to your questions, but the technical details of the proposal were intentionally left out because we simply haven't convened to discuss anything in concretions yet. However, I can give you my thoughts on where I'd like to take this, personally: Is it simply about creating a contribution process (which already exists afaik, it's just that you barely get any response for core libraries) A contribution process is one part of it, and it's a little more complicated than the situation you describe. Mainly, yes, a contribution process exists and the CLC has been historically poor at answering the call. However, this is not simply because the CLC has been derelict - my contention is that it was never very efficient, and has simply been completely defunct for some time now. Here are some thoughts I have on the matter off the top of my head for how we can improve things: 1. I feel (as do others in the CLC and outside of it) that the mailing list is good for some contributions, but poor for others. Namely, some contributions to base are small enough that they should occur as a pull request against `base`, a ping to the CLC, and we should review it without getting everyone who monitors this list involved. Historically, contributions that are small in scope, and possibly trivial quality of life contributions are defeated by bikeshedding. Too many cooks is a very real phenomenon in this mailing list. We would like to make sure that the process for deciding where to submit an idea is well documented, and that it is a separate avenue. 2. For mid-sized contributions, the mailing list is great! However, there does seem to be a culture, particularly in this list of not being oriented towards solutions. There is not enough skin in the game. I get the impression in many cases (and others have expressed similar complaints) that many interactions are simply "gotcha"-style intellectual mounting games instead of solution finding, and this causes alot of frustration consistently enough for people to voice the complaint to me. 3. For larger contributions, like the Abstract file path proposal, I think a mailing list is perhaps too small a forum to discuss it, and it would be better served by a GHC proposal-style process that is more open for comment, searchable, and and history not so scattered. Further, without a project manager for larger contributions, these things get lost easily, and we would like to solve that by adding a role, and reworking the process for larger, overarching changes to `base`. 4. Mailing lists are generally not friendly to searches, history, or finding out who's in charge of what. In addition to this, what I have in mind is to add more members to the CLC, to allow for a more fluid process for onboarding and offboarding CLC members as they become or fall out of availability. I would also like to lower the bar, as you suggested on Reddit might be a good idea. I don't think requiring galaxy brains is the right tack we need to take. I would rather have productive engineers who can bring new ideas to the table about how to improve the state of `base`. contribution pipeline through the HF? This is not in our plans, though, we have spoken a little bit about whether or not someone from the HF could serve as a shepherd for issues and CLC member wrangler. However, I don't think this would be in any official HF capacity as much as it would be a good will gesture. Mainly though, a project manager is in our interests, be it an HF person or not. Cheers, Emily On Tue, Aug 10, 2021 at 11:52 PM, Julian Ospald > wrote: On August 10, 2021 9:01:22 PM UTC, Emily Pillmore > wrote: I expect that the structure of the CLC will scale back to maintaining `base` as a main focus, with a new proposal process in the vein of the Haskell Foundation or GHC tech proposals process, and the designation of new roles to help shepherd issues to us and manage contributors. Can you be more precise here? Is it simply about creating a contribution process (which already exists afaik, it's just that you barely get any response for core libraries) or is the idea to run part of the contribution pipeline through the HF? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ~WRD0567.jpg Type: image/jpeg Size: 823 bytes Desc: ~WRD0567.jpg URL: From hasufell at posteo.de Thu Aug 12 16:24:47 2021 From: hasufell at posteo.de (Julian Ospald) Date: Thu, 12 Aug 2021 16:24:47 +0000 Subject: State of the CLC [wrt MLs] In-Reply-To: References: Message-ID: <167EF3C8-2081-4F7B-BD06-9CBE5E9691B7@posteo.de> I totally agree. Here's where we need active moderation. While a thread develops, I'd expect the moderator at one point to set a stop sign, gather the different ideas, summarize them as a reply to the top-post with the subject changed and then have CLC do their voting. That way, CLC members not actively participating in the thread can get a reasonable overview of the options. The outcome should be posted as a reply to that mail, however, as you pointed out, ML is not a structured document. I'd say it's up to the discretion of the CLC to choose and maintain a record of the discussions and their status and the decisions, be that google docs, a gitlab repo etc., containing ML archive links and other relevant resources. On August 12, 2021 3:20:46 PM UTC, Simon Peyton Jones wrote: >Fair enough Julian. Any system that allows rapid, unequivocal, and universally-agreed answers to the questions I list below would be fine with me. I don't quite see how email can do that (e.g. press a button to list the proposals under committee review), but if it can, so much the better. > >Oh, I should add one more: > > * What exactly is the proposal that the committee has accepted? One should be able to answer that by pointing to a (perhaps short) document or PR. It is much much less good to reply "It's the proposal made in this email, and then modified and fine-tuned by the following 20". >Email is good for the process and discussion; it is less good at recording the outcome and decision. > >Simon > >From: Julian Ospald >Sent: 12 August 2021 13:49 >To: Simon Peyton Jones ; Emily Pillmore >Cc: libraries at haskell.org >Subject: RE: State of the CLC [wrt MLs] > >I'm not sure Simon, > >many projects larger than the CLC are using mailing lists with much higher throughput: > >* https://lkml.org/ >* https://archives.gentoo.org/gentoo-dev/threads >* https://lists.debian.org/ > >These have done so for decades and had enough time to consider alternatives. > >To get into more detail: > >1. Mails have threads! But one has to use them properly. The subject when creating a reply can be adjusted as well. >2. Cross-posting is very easy. Much easier than jumping between reddit, discourse and github PRs. >3. They can be used for patches and reviews as well and many projects still use this mechanism. You don't even have to use git for that. I'm not advocating for that, but it shows that it's a very simple and powerful communication tool, even today. >4. They are persistent and searchable through ML archives. > >I believe this just boils down to communication discipline and moderation. In lack of both, I believe no matter the tool, the experience won't be pleasant (issue tracker discussions are worse imo, since they often don't have good threading). > >Cheers, >Julian >On August 12, 2021 8:00:30 AM UTC, Simon Peyton Jones wrote: >I'd like to suggest that a mailing list isn't good even for mis-sized contributions. > >One of the difficulties of managing the CLC process is that it often consists of a number of small proposals, all in flight. It's very easy for them to get lost and - especially because they are small - that is very frustrating for the contributor. > >I think it would help to have mechanical support of some kind, that makes it easy to answer questions like > > > * What proposed changes to `base` and `ghc-prim` are in flight? (No matter how small!) > * Which of those changes are in "open-discussion" mode (relaxed timescale), and which have been submitted to the committee for decision (fixed timescale). For the latter, on what date was the proposal submitted? > * What decisions has the committee taken? To accept, or reject, or push-back a proposal? > >A mailing list is poorly adapted to answering these questions. But I think much frustration arises not because anyone is being lazy or negligent, but simply because volunteers are busy, and it's hard to keep multiple threads going in your head and all too easy for them to drift - sometimes for ever. > >It's almost more important to do this to keep track of the many small proposals than for the few big ones. > >Using PRs is one sort of mechanical support, provided there is some kind of tagging giving the status (in-discussion, under-committee-review, accepted, rejected) of each. > >I'm not directly involved in CLC, so these are just suggestions. > >Simon > >From: Libraries On Behalf Of Emily Pillmore >Sent: 12 August 2021 00:16 >To: Julian Ospald >Cc: libraries at haskell.org >Subject: Re: State of the CLC > >You really know how to get right to the heart of where I'm being intentionally vague and asking questions about it! :) > >I can speak a little bit to your questions, but the technical details of the proposal were intentionally left out because we simply haven't convened to discuss anything in concretions yet. However, I can give you my thoughts on where I'd like to take this, personally: >Is it simply about creating a contribution process (which already exists afaik, it's just that you barely get any response for core libraries) > >A contribution process is one part of it, and it's a little more complicated than the situation you describe. Mainly, yes, a contribution process exists and the CLC has been historically poor at answering the call. However, this is not simply because the CLC has been derelict - my contention is that it was never very efficient, and has simply been completely defunct for some time now. Here are some thoughts I have on the matter off the top of my head for how we can improve things: > > 1. I feel (as do others in the CLC and outside of it) that the mailing list is good for some contributions, but poor for others. Namely, some contributions to base are small enough that they should occur as a pull request against `base`, a ping to the CLC, and we should review it without getting everyone who monitors this list involved. Historically, contributions that are small in scope, and possibly trivial quality of life contributions are defeated by bikeshedding. Too many cooks is a very real phenomenon in this mailing list. We would like to make sure that the process for deciding where to submit an idea is well documented, and that it is a separate avenue. > 2. For mid-sized contributions, the mailing list is great! However, there does seem to be a culture, particularly in this list of not being oriented towards solutions. There is not enough skin in the game. I get the impression in many cases (and others have expressed similar complaints) that many interactions are simply "gotcha"-style intellectual mounting games instead of solution finding, and this causes alot of frustration consistently enough for people to voice the complaint to me. > 3. For larger contributions, like the Abstract file path proposal, I think a mailing list is perhaps too small a forum to discuss it, and it would be better served by a GHC proposal-style process that is more open for comment, searchable, and and history not so scattered. Further, without a project manager for larger contributions, these things get lost easily, and we would like to solve that by adding a role, and reworking the process for larger, overarching changes to `base`. > 4. Mailing lists are generally not friendly to searches, history, or finding out who's in charge of what. > >In addition to this, what I have in mind is to add more members to the CLC, to allow for a more fluid process for onboarding and offboarding CLC members as they become or fall out of availability. I would also like to lower the bar, as you suggested on Reddit might be a good idea. I don't think requiring galaxy brains is the right tack we need to take. I would rather have productive engineers who can bring new ideas to the table about how to improve the state of `base`. > >contribution pipeline through the HF? > >This is not in our plans, though, we have spoken a little bit about whether or not someone from the HF could serve as a shepherd for issues and CLC member wrangler. However, I don't think this would be in any official HF capacity as much as it would be a good will gesture. Mainly though, a project manager is in our interests, be it an HF person or not. > >Cheers, >Emily > > > > > > > >On Tue, Aug 10, 2021 at 11:52 PM, Julian Ospald > wrote: > >On August 10, 2021 9:01:22 PM UTC, Emily Pillmore > wrote: > >I expect that the structure of the CLC will scale back to maintaining `base` as a main focus, with a new proposal process in the vein of the Haskell Foundation or GHC tech proposals process, and the designation of new roles to help shepherd issues to us and manage contributors. > >Can you be more precise here? Is it simply about creating a contribution process (which already exists afaik, it's just that you barely get any response for core libraries) or is the idea to run part of the contribution pipeline through the HF? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Aug 12 17:04:30 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 12 Aug 2021 17:04:30 +0000 Subject: State of the CLC [wrt MLs] In-Reply-To: <167EF3C8-2081-4F7B-BD06-9CBE5E9691B7@posteo.de> References: <167EF3C8-2081-4F7B-BD06-9CBE5E9691B7@posteo.de> Message-ID: I'd say it's up to the discretion of the CLC to choose and maintain a record of the discussions and their status and the decisions, be that google docs, a gitlab repo etc., containing ML archive links and other relevant resources. I'm totally with you on that. The CLC should decide how the CLC should operate. I'm just trying to contribute constructively to the debate. Simon From: Julian Ospald Sent: 12 August 2021 17:25 To: Simon Peyton Jones ; Emily Pillmore Cc: libraries at haskell.org Subject: RE: State of the CLC [wrt MLs] I totally agree. Here's where we need active moderation. While a thread develops, I'd expect the moderator at one point to set a stop sign, gather the different ideas, summarize them as a reply to the top-post with the subject changed and then have CLC do their voting. That way, CLC members not actively participating in the thread can get a reasonable overview of the options. The outcome should be posted as a reply to that mail, however, as you pointed out, ML is not a structured document. I'd say it's up to the discretion of the CLC to choose and maintain a record of the discussions and their status and the decisions, be that google docs, a gitlab repo etc., containing ML archive links and other relevant resources. On August 12, 2021 3:20:46 PM UTC, Simon Peyton Jones > wrote: Fair enough Julian. Any system that allows rapid, unequivocal, and universally-agreed answers to the questions I list below would be fine with me. I don't quite see how email can do that (e.g. press a button to list the proposals under committee review), but if it can, so much the better. Oh, I should add one more: * What exactly is the proposal that the committee has accepted? One should be able to answer that by pointing to a (perhaps short) document or PR. It is much much less good to reply "It's the proposal made in this email, and then modified and fine-tuned by the following 20". Email is good for the process and discussion; it is less good at recording the outcome and decision. Simon From: Julian Ospald > Sent: 12 August 2021 13:49 To: Simon Peyton Jones >; Emily Pillmore > Cc: libraries at haskell.org Subject: RE: State of the CLC [wrt MLs] I'm not sure Simon, many projects larger than the CLC are using mailing lists with much higher throughput: * https://lkml.org/ * https://archives.gentoo.org/gentoo-dev/threads * https://lists.debian.org/ These have done so for decades and had enough time to consider alternatives. To get into more detail: 1. Mails have threads! But one has to use them properly. The subject when creating a reply can be adjusted as well. 2. Cross-posting is very easy. Much easier than jumping between reddit, discourse and github PRs. 3. They can be used for patches and reviews as well and many projects still use this mechanism. You don't even have to use git for that. I'm not advocating for that, but it shows that it's a very simple and powerful communication tool, even today. 4. They are persistent and searchable through ML archives. I believe this just boils down to communication discipline and moderation. In lack of both, I believe no matter the tool, the experience won't be pleasant (issue tracker discussions are worse imo, since they often don't have good threading). Cheers, Julian On August 12, 2021 8:00:30 AM UTC, Simon Peyton Jones > wrote: I'd like to suggest that a mailing list isn't good even for mis-sized contributions. One of the difficulties of managing the CLC process is that it often consists of a number of small proposals, all in flight. It's very easy for them to get lost and - especially because they are small - that is very frustrating for the contributor. I think it would help to have mechanical support of some kind, that makes it easy to answer questions like * What proposed changes to `base` and `ghc-prim` are in flight? (No matter how small!) * Which of those changes are in "open-discussion" mode (relaxed timescale), and which have been submitted to the committee for decision (fixed timescale). For the latter, on what date was the proposal submitted? * What decisions has the committee taken? To accept, or reject, or push-back a proposal? A mailing list is poorly adapted to answering these questions. But I think much frustration arises not because anyone is being lazy or negligent, but simply because volunteers are busy, and it's hard to keep multiple threads going in your head and all too easy for them to drift - sometimes for ever. It's almost more important to do this to keep track of the many small proposals than for the few big ones. Using PRs is one sort of mechanical support, provided there is some kind of tagging giving the status (in-discussion, under-committee-review, accepted, rejected) of each. I'm not directly involved in CLC, so these are just suggestions. Simon From: Libraries > On Behalf Of Emily Pillmore Sent: 12 August 2021 00:16 To: Julian Ospald > Cc: libraries at haskell.org Subject: Re: State of the CLC You really know how to get right to the heart of where I'm being intentionally vague and asking questions about it! :) I can speak a little bit to your questions, but the technical details of the proposal were intentionally left out because we simply haven't convened to discuss anything in concretions yet. However, I can give you my thoughts on where I'd like to take this, personally: Is it simply about creating a contribution process (which already exists afaik, it's just that you barely get any response for core libraries) A contribution process is one part of it, and it's a little more complicated than the situation you describe. Mainly, yes, a contribution process exists and the CLC has been historically poor at answering the call. However, this is not simply because the CLC has been derelict - my contention is that it was never very efficient, and has simply been completely defunct for some time now. Here are some thoughts I have on the matter off the top of my head for how we can improve things: 1. I feel (as do others in the CLC and outside of it) that the mailing list is good for some contributions, but poor for others. Namely, some contributions to base are small enough that they should occur as a pull request against `base`, a ping to the CLC, and we should review it without getting everyone who monitors this list involved. Historically, contributions that are small in scope, and possibly trivial quality of life contributions are defeated by bikeshedding. Too many cooks is a very real phenomenon in this mailing list. We would like to make sure that the process for deciding where to submit an idea is well documented, and that it is a separate avenue. 2. For mid-sized contributions, the mailing list is great! However, there does seem to be a culture, particularly in this list of not being oriented towards solutions. There is not enough skin in the game. I get the impression in many cases (and others have expressed similar complaints) that many interactions are simply "gotcha"-style intellectual mounting games instead of solution finding, and this causes alot of frustration consistently enough for people to voice the complaint to me. 3. For larger contributions, like the Abstract file path proposal, I think a mailing list is perhaps too small a forum to discuss it, and it would be better served by a GHC proposal-style process that is more open for comment, searchable, and and history not so scattered. Further, without a project manager for larger contributions, these things get lost easily, and we would like to solve that by adding a role, and reworking the process for larger, overarching changes to `base`. 4. Mailing lists are generally not friendly to searches, history, or finding out who's in charge of what. In addition to this, what I have in mind is to add more members to the CLC, to allow for a more fluid process for onboarding and offboarding CLC members as they become or fall out of availability. I would also like to lower the bar, as you suggested on Reddit might be a good idea. I don't think requiring galaxy brains is the right tack we need to take. I would rather have productive engineers who can bring new ideas to the table about how to improve the state of `base`. contribution pipeline through the HF? This is not in our plans, though, we have spoken a little bit about whether or not someone from the HF could serve as a shepherd for issues and CLC member wrangler. However, I don't think this would be in any official HF capacity as much as it would be a good will gesture. Mainly though, a project manager is in our interests, be it an HF person or not. Cheers, Emily On Tue, Aug 10, 2021 at 11:52 PM, Julian Ospald > wrote: On August 10, 2021 9:01:22 PM UTC, Emily Pillmore > wrote: I expect that the structure of the CLC will scale back to maintaining `base` as a main focus, with a new proposal process in the vein of the Haskell Foundation or GHC tech proposals process, and the designation of new roles to help shepherd issues to us and manage contributors. Can you be more precise here? Is it simply about creating a contribution process (which already exists afaik, it's just that you barely get any response for core libraries) or is the idea to run part of the contribution pipeline through the HF? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hasufell at posteo.de Thu Aug 12 17:51:22 2021 From: hasufell at posteo.de (Julian Ospald) Date: Thu, 12 Aug 2021 17:51:22 +0000 Subject: State of the CLC [wrt MLs] In-Reply-To: References: <167EF3C8-2081-4F7B-BD06-9CBE5E9691B7@posteo.de> Message-ID: Absolutely. I propose to make this a role: CLC secretary. Someone actively moderating discussions, ensuring community participation on proposals, summarizing results, maintaining the records. The same person may be part of the CLC committee, but doesn't need to be. Cheers, Julian On August 12, 2021 5:04:30 PM UTC, Simon Peyton Jones wrote: >I'd say it's up to the discretion of the CLC to choose and maintain a record of the discussions and their status and the decisions, be that google docs, a gitlab repo etc., containing ML archive links and other relevant resources. > >I'm totally with you on that. The CLC should decide how the CLC should operate. I'm just trying to contribute constructively to the debate. > >Simon > > >From: Julian Ospald >Sent: 12 August 2021 17:25 >To: Simon Peyton Jones ; Emily Pillmore >Cc: libraries at haskell.org >Subject: RE: State of the CLC [wrt MLs] > >I totally agree. > >Here's where we need active moderation. While a thread develops, I'd expect the moderator at one point to set a stop sign, gather the different ideas, summarize them as a reply to the top-post with the subject changed and then have CLC do their voting. That way, CLC members not actively participating in the thread can get a reasonable overview of the options. > >The outcome should be posted as a reply to that mail, however, as you pointed out, ML is not a structured document. > >I'd say it's up to the discretion of the CLC to choose and maintain a record of the discussions and their status and the decisions, be that google docs, a gitlab repo etc., containing ML archive links and other relevant resources. >On August 12, 2021 3:20:46 PM UTC, Simon Peyton Jones > wrote: >Fair enough Julian. Any system that allows rapid, unequivocal, and universally-agreed answers to the questions I list below would be fine with me. I don't quite see how email can do that (e.g. press a button to list the proposals under committee review), but if it can, so much the better. > >Oh, I should add one more: > > * What exactly is the proposal that the committee has accepted? One should be able to answer that by pointing to a (perhaps short) document or PR. It is much much less good to reply "It's the proposal made in this email, and then modified and fine-tuned by the following 20". >Email is good for the process and discussion; it is less good at recording the outcome and decision. > >Simon > >From: Julian Ospald > >Sent: 12 August 2021 13:49 >To: Simon Peyton Jones >; Emily Pillmore > >Cc: libraries at haskell.org >Subject: RE: State of the CLC [wrt MLs] > >I'm not sure Simon, > >many projects larger than the CLC are using mailing lists with much higher throughput: > >* https://lkml.org/ >* https://archives.gentoo.org/gentoo-dev/threads >* https://lists.debian.org/ > >These have done so for decades and had enough time to consider alternatives. > >To get into more detail: > >1. Mails have threads! But one has to use them properly. The subject when creating a reply can be adjusted as well. >2. Cross-posting is very easy. Much easier than jumping between reddit, discourse and github PRs. >3. They can be used for patches and reviews as well and many projects still use this mechanism. You don't even have to use git for that. I'm not advocating for that, but it shows that it's a very simple and powerful communication tool, even today. >4. They are persistent and searchable through ML archives. > >I believe this just boils down to communication discipline and moderation. In lack of both, I believe no matter the tool, the experience won't be pleasant (issue tracker discussions are worse imo, since they often don't have good threading). > >Cheers, >Julian >On August 12, 2021 8:00:30 AM UTC, Simon Peyton Jones > wrote: >I'd like to suggest that a mailing list isn't good even for mis-sized contributions. > >One of the difficulties of managing the CLC process is that it often consists of a number of small proposals, all in flight. It's very easy for them to get lost and - especially because they are small - that is very frustrating for the contributor. > >I think it would help to have mechanical support of some kind, that makes it easy to answer questions like > > > * What proposed changes to `base` and `ghc-prim` are in flight? (No matter how small!) > * Which of those changes are in "open-discussion" mode (relaxed timescale), and which have been submitted to the committee for decision (fixed timescale). For the latter, on what date was the proposal submitted? > * What decisions has the committee taken? To accept, or reject, or push-back a proposal? > >A mailing list is poorly adapted to answering these questions. But I think much frustration arises not because anyone is being lazy or negligent, but simply because volunteers are busy, and it's hard to keep multiple threads going in your head and all too easy for them to drift - sometimes for ever. > >It's almost more important to do this to keep track of the many small proposals than for the few big ones. > >Using PRs is one sort of mechanical support, provided there is some kind of tagging giving the status (in-discussion, under-committee-review, accepted, rejected) of each. > >I'm not directly involved in CLC, so these are just suggestions. > >Simon > >From: Libraries > On Behalf Of Emily Pillmore >Sent: 12 August 2021 00:16 >To: Julian Ospald > >Cc: libraries at haskell.org >Subject: Re: State of the CLC > >You really know how to get right to the heart of where I'm being intentionally vague and asking questions about it! :) > >I can speak a little bit to your questions, but the technical details of the proposal were intentionally left out because we simply haven't convened to discuss anything in concretions yet. However, I can give you my thoughts on where I'd like to take this, personally: >Is it simply about creating a contribution process (which already exists afaik, it's just that you barely get any response for core libraries) > >A contribution process is one part of it, and it's a little more complicated than the situation you describe. Mainly, yes, a contribution process exists and the CLC has been historically poor at answering the call. However, this is not simply because the CLC has been derelict - my contention is that it was never very efficient, and has simply been completely defunct for some time now. Here are some thoughts I have on the matter off the top of my head for how we can improve things: > > 1. I feel (as do others in the CLC and outside of it) that the mailing list is good for some contributions, but poor for others. Namely, some contributions to base are small enough that they should occur as a pull request against `base`, a ping to the CLC, and we should review it without getting everyone who monitors this list involved. Historically, contributions that are small in scope, and possibly trivial quality of life contributions are defeated by bikeshedding. Too many cooks is a very real phenomenon in this mailing list. We would like to make sure that the process for deciding where to submit an idea is well documented, and that it is a separate avenue. > 2. For mid-sized contributions, the mailing list is great! However, there does seem to be a culture, particularly in this list of not being oriented towards solutions. There is not enough skin in the game. I get the impression in many cases (and others have expressed similar complaints) that many interactions are simply "gotcha"-style intellectual mounting games instead of solution finding, and this causes alot of frustration consistently enough for people to voice the complaint to me. > 3. For larger contributions, like the Abstract file path proposal, I think a mailing list is perhaps too small a forum to discuss it, and it would be better served by a GHC proposal-style process that is more open for comment, searchable, and and history not so scattered. Further, without a project manager for larger contributions, these things get lost easily, and we would like to solve that by adding a role, and reworking the process for larger, overarching changes to `base`. > 4. Mailing lists are generally not friendly to searches, history, or finding out who's in charge of what. > >In addition to this, what I have in mind is to add more members to the CLC, to allow for a more fluid process for onboarding and offboarding CLC members as they become or fall out of availability. I would also like to lower the bar, as you suggested on Reddit might be a good idea. I don't think requiring galaxy brains is the right tack we need to take. I would rather have productive engineers who can bring new ideas to the table about how to improve the state of `base`. > >contribution pipeline through the HF? > >This is not in our plans, though, we have spoken a little bit about whether or not someone from the HF could serve as a shepherd for issues and CLC member wrangler. However, I don't think this would be in any official HF capacity as much as it would be a good will gesture. Mainly though, a project manager is in our interests, be it an HF person or not. > >Cheers, >Emily > > > > > > > >On Tue, Aug 10, 2021 at 11:52 PM, Julian Ospald > wrote: > >On August 10, 2021 9:01:22 PM UTC, Emily Pillmore > wrote: > >I expect that the structure of the CLC will scale back to maintaining `base` as a main focus, with a new proposal process in the vein of the Haskell Foundation or GHC tech proposals process, and the designation of new roles to help shepherd issues to us and manage contributors. > >Can you be more precise here? Is it simply about creating a contribution process (which already exists afaik, it's just that you barely get any response for core libraries) or is the idea to run part of the contribution pipeline through the HF? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Aug 12 18:54:47 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 12 Aug 2021 11:54:47 -0700 Subject: State of the CLC [wrt MLs] In-Reply-To: References: <167EF3C8-2081-4F7B-BD06-9CBE5E9691B7@posteo.de> Message-ID: Yeah that’s def been needed for the longest time. On Thu, Aug 12, 2021 at 10:52 AM Julian Ospald wrote: > Absolutely. > > I propose to make this a role: CLC secretary. Someone actively moderating > discussions, ensuring community participation on proposals, summarizing > results, maintaining the records. > > The same person may be part of the CLC committee, but doesn't need to be. > > Cheers, > Julian > > > On August 12, 2021 5:04:30 PM UTC, Simon Peyton Jones < > simonpj at microsoft.com> wrote: >> >> I'd say it's up to the discretion of the CLC to choose and maintain a >> record of the discussions and their status and the decisions, be that >> google docs, a gitlab repo etc., containing ML archive links and other >> relevant resources. >> >> >> >> I’m totally with you on that. The CLC should decide how the CLC should >> operate. I’m just trying to contribute constructively to the debate. >> >> >> >> Simon >> >> >> >> >> >> *From:* Julian Ospald >> *Sent:* 12 August 2021 17:25 >> *To:* Simon Peyton Jones ; Emily Pillmore < >> emilypi at cohomolo.gy> >> *Cc:* libraries at haskell.org >> *Subject:* RE: State of the CLC [wrt MLs] >> >> >> >> I totally agree. >> >> Here's where we need active moderation. While a thread develops, I'd >> expect the moderator at one point to set a stop sign, gather the different >> ideas, summarize them as a reply to the top-post with the subject changed >> and then have CLC do their voting. That way, CLC members not actively >> participating in the thread can get a reasonable overview of the options. >> >> The outcome should be posted as a reply to that mail, however, as you >> pointed out, ML is not a structured document. >> >> I'd say it's up to the discretion of the CLC to choose and maintain a >> record of the discussions and their status and the decisions, be that >> google docs, a gitlab repo etc., containing ML archive links and other >> relevant resources. >> >> On August 12, 2021 3:20:46 PM UTC, Simon Peyton Jones < >> simonpj at microsoft.com> wrote: >> >> Fair enough Julian. Any system that allows rapid, unequivocal, and >> universally-agreed answers to the questions I list below would be fine with >> me. I don’t quite see how email can do that (e.g. press a button to list >> the proposals under committee review), but if it can, so much the better. >> >> >> >> Oh, I should add one more: >> >> - What exactly *is* the proposal that the committee has accepted? >> One should be able to answer that by pointing to a (perhaps short) document >> or PR. It is much much less good to reply “It’s the proposal made in this >> email, and then modified and fine-tuned by the following 20”. >> >> Email is good for the *process *and *discussion*; it is less good at >> recording the *outcome *and *decision*. >> >> >> >> Simon >> >> >> >> *From:* Julian Ospald >> *Sent:* 12 August 2021 13:49 >> *To:* Simon Peyton Jones ; Emily Pillmore < >> emilypi at cohomolo.gy> >> *Cc:* libraries at haskell.org >> *Subject:* RE: State of the CLC [wrt MLs] >> >> >> >> I'm not sure Simon, >> >> many projects larger than the CLC are using mailing lists with much >> higher throughput: >> >> * https://lkml.org/ >> >> * https://archives.gentoo.org/gentoo-dev/threads >> >> * https://lists.debian.org/ >> >> >> These have done so for decades and had enough time to consider >> alternatives. >> >> To get into more detail: >> >> 1. Mails have threads! But one has to use them properly. The subject when >> creating a reply can be adjusted as well. >> 2. Cross-posting is very easy. Much easier than jumping between reddit, >> discourse and github PRs. >> 3. They can be used for patches and reviews as well and many projects >> still use this mechanism. You don't even have to use git for that. I'm not >> advocating for that, but it shows that it's a very simple and powerful >> communication tool, even today. >> 4. They are persistent and searchable through ML archives. >> >> I believe this just boils down to communication discipline and >> moderation. In lack of both, I believe no matter the tool, the experience >> won't be pleasant (issue tracker discussions are worse imo, since they >> often don't have good threading). >> >> Cheers, >> Julian >> >> On August 12, 2021 8:00:30 AM UTC, Simon Peyton Jones < >> simonpj at microsoft.com> wrote: >> >> I’d like to suggest that a mailing list isn’t good even for mis-sized >> contributions. >> >> >> >> One of the difficulties of managing the CLC process is that it often >> consists of a number of small proposals, all in flight. It’s very easy for >> them to get lost and – especially because they are small – that is very >> frustrating for the contributor. >> >> >> >> I think it would help to have mechanical support of some kind, that makes >> it easy to answer questions like >> >> >> >> - What proposed changes to `base` and `ghc-prim` are in flight? (No >> matter how small!) >> - Which of those changes are in “open-discussion” mode (relaxed >> timescale), and which have been submitted to the committee for decision >> (fixed timescale). For the latter, on what date was the proposal submitted? >> - What decisions has the committee taken? To accept, or reject, or >> push-back a proposal? >> >> >> >> A mailing list is poorly adapted to answering these questions. But I >> think much frustration arises not because anyone is being lazy or >> negligent, but simply because volunteers are busy, and it’s hard to keep >> multiple threads going in your head and all too easy for them to drift – >> sometimes for ever. >> >> >> >> It’s almost more important to do this to keep track of the many small >> proposals than for the few big ones. >> >> >> >> Using PRs is one sort of mechanical support, provided there is some kind >> of tagging giving the status (in-discussion, under-committee-review, >> accepted, rejected) of each. >> >> >> >> I’m not directly involved in CLC, so these are just suggestions. >> >> >> >> Simon >> >> >> >> *From:* Libraries *On Behalf Of *Emily >> Pillmore >> *Sent:* 12 August 2021 00:16 >> *To:* Julian Ospald >> *Cc:* libraries at haskell.org >> *Subject:* Re: State of the CLC >> >> >> >> You really know how to get right to the heart of where I'm being >> intentionally vague and asking questions about it! :) >> >> I can speak a little bit to your questions, but the technical details of >> the proposal were intentionally left out because we simply haven't convened >> to discuss anything in concretions yet. However, I can give you my thoughts >> on where I'd like to take this, personally: >> >> Is it simply about creating a contribution process (which already exists >> afaik, it's just that you barely get any response for core libraries) >> >> >> >> A contribution process is one part of it, and it's a little more >> complicated than the situation you describe. Mainly, yes, a contribution >> process exists and the CLC has been historically poor at answering the >> call. However, this is not simply because the CLC has been derelict - my >> contention is that it was never very efficient, and has simply been >> completely defunct for some time now. Here are some thoughts I have on the >> matter off the top of my head for how we can improve things: >> >> 1. I feel (as do others in the CLC and outside of it) that the >> mailing list is good for some contributions, but poor for others. Namely, >> some contributions to base are small enough that they should occur as a >> pull request against `base`, a ping to the CLC, and we should review it >> without getting everyone who monitors this list involved. Historically, >> contributions that are small in scope, and possibly trivial quality of life >> contributions are defeated by bikeshedding. Too many cooks is a very real >> phenomenon in this mailing list. We would like to make sure that the >> process for deciding where to submit an idea is well documented, and that >> it is a separate avenue. >> 2. For mid-sized contributions, the mailing list is great! However, >> there does seem to be a culture, particularly in this list of not being >> oriented towards solutions. There is not enough skin in the game. I get the >> impression in many cases (and others have expressed similar complaints) >> that many interactions are simply "gotcha"-style intellectual mounting >> games instead of solution finding, and this causes alot of frustration >> consistently enough for people to voice the complaint to me. >> 3. For larger contributions, like the Abstract file path proposal, I >> think a mailing list is perhaps too small a forum to discuss it, and it >> would be better served by a GHC proposal-style process that is more open >> for comment, searchable, and and history not so scattered. Further, without >> a project manager for larger contributions, these things get lost easily, >> and we would like to solve that by adding a role, and reworking the process >> for larger, overarching changes to `base`. >> 4. Mailing lists are generally not friendly to searches, history, or >> finding out who's in charge of what. >> >> >> >> In addition to this, what I have in mind is to add more members to the >> CLC, to allow for a more fluid process for onboarding and offboarding CLC >> members as they become or fall out of availability. I would also like to >> lower the bar, as you suggested on Reddit might be a good idea. I don't >> think requiring galaxy brains is the right tack we need to take. I would >> rather have productive engineers who can bring new ideas to the table about >> how to improve the state of `base`. >> >> >> >> contribution pipeline through the HF? >> >> >> >> This is not in our plans, though, we have spoken a little bit about >> whether or not someone from the HF could serve as a shepherd for issues and >> CLC member wrangler. However, I don't think this would be in any official >> HF capacity as much as it would be a good will gesture. Mainly though, a >> project manager is in our interests, be it an HF person or not. >> >> >> >> Cheers, >> >> Emily >> >> >> >> >> >> >> >> >> >> [image: Image removed by sender.] >> >> >> >> >> >> On Tue, Aug 10, 2021 at 11:52 PM, Julian Ospald >> wrote: >> >> On August 10, 2021 9:01:22 PM UTC, Emily Pillmore >> wrote: >> >> I expect that the structure of the CLC will scale back to maintaining >> `base` as a main focus, with a new proposal process in the vein of the >> Haskell Foundation or GHC tech proposals process, and the designation of >> new roles to help shepherd issues to us and manage contributors. >> >> Can you be more precise here? Is it simply about creating a contribution >> process (which already exists afaik, it's just that you barely get any >> response for core libraries) or is the idea to run part of the contribution >> pipeline through the HF? >> >> >> >> _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.abel at ifi.lmu.de Sat Aug 14 16:53:08 2021 From: andreas.abel at ifi.lmu.de (Andreas Abel) Date: Sat, 14 Aug 2021 18:53:08 +0200 Subject: How to use Read for Data.Version Message-ID: <760f54e8-8b78-23fd-4516-75a24ca93ebd@ifi.lmu.de> How is the parser for Data.Version supposed to work? ```haskell import Data.Version readVersion :: String -> Version readVersion = read main :: IO () main = print $ readVersion "8.10.5" -- *** Exception: Prelude.read: no parse ``` P.S.: Maintainer libraries at haskell.org From chessai1996 at gmail.com Sat Aug 14 17:06:54 2021 From: chessai1996 at gmail.com (chessai) Date: Sat, 14 Aug 2021 12:06:54 -0500 Subject: How to use Read for Data.Version In-Reply-To: <760f54e8-8b78-23fd-4516-75a24ca93ebd@ifi.lmu.de> References: <760f54e8-8b78-23fd-4516-75a24ca93ebd@ifi.lmu.de> Message-ID: Looking at the source code [1], Read is derived, and not using parseVersion (which has the behaviour I think you expect). You may want to use parseVersion directly. [1]: https://hackage.haskell.org/package/base-4.15.0.0/docs/src/Data-Version.html On Sat, Aug 14, 2021, 11:55 Andreas Abel wrote: > How is the parser for Data.Version supposed to work? > > ```haskell > import Data.Version > > readVersion :: String -> Version > readVersion = read > > main :: IO () > main = print $ readVersion "8.10.5" > > -- *** Exception: Prelude.read: no parse > ``` > > P.S.: Maintainer libraries at haskell.org > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.abel at ifi.lmu.de Sat Aug 14 17:09:16 2021 From: andreas.abel at ifi.lmu.de (Andreas Abel) Date: Sat, 14 Aug 2021 19:09:16 +0200 Subject: How to use Read for Data.Version In-Reply-To: References: <760f54e8-8b78-23fd-4516-75a24ca93ebd@ifi.lmu.de> Message-ID: Thanks for the quick answer. Indeed, I confused Read and ReadP! --Andreas On 2021-08-14 19:06, chessai wrote: > Looking at the source code [1], Read is derived, and not using > parseVersion (which has the behaviour I think you expect). > > You may want to use parseVersion directly. > > [1]: > https://hackage.haskell.org/package/base-4.15.0.0/docs/src/Data-Version.html > > > On Sat, Aug 14, 2021, 11:55 Andreas Abel > wrote: > > How is the parser for Data.Version supposed to work? > > ```haskell > import Data.Version > > readVersion :: String -> Version > readVersion = read > > main :: IO () > main = print $ readVersion "8.10.5" > > -- *** Exception: Prelude.read: no parse > ``` > > P.S.: Maintainer libraries at haskell.org > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sat Aug 14 17:10:49 2021 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 14 Aug 2021 18:10:49 +0100 Subject: How to use Read for Data.Version In-Reply-To: <760f54e8-8b78-23fd-4516-75a24ca93ebd@ifi.lmu.de> References: <760f54e8-8b78-23fd-4516-75a24ca93ebd@ifi.lmu.de> Message-ID: <20210814171049.GB26993@cloudinit-builder> On Sat, Aug 14, 2021 at 06:53:08PM +0200, Andreas Abel wrote: > How is the parser for Data.Version supposed to work? > > ```haskell > import Data.Version > > readVersion :: String -> Version > readVersion = read > > main :: IO () > main = print $ readVersion "8.10.5" > > -- *** Exception: Prelude.read: no parse > ``` The Read instance is derived https://hackage.haskell.org/package/base-4.15.0.0/docs/src/Data-Version.html#Version so it behaves like any other derived Read instance: Prelude Data.Version> read "Version {versionBranch = [8,10,5], versionTags = []}" :: Version Version {versionBranch = [8,10,5], versionTags = []} Tom From ietf-dane at dukhovni.org Sat Aug 14 17:13:53 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 14 Aug 2021 13:13:53 -0400 Subject: How to use Read for Data.Version In-Reply-To: <760f54e8-8b78-23fd-4516-75a24ca93ebd@ifi.lmu.de> References: <760f54e8-8b78-23fd-4516-75a24ca93ebd@ifi.lmu.de> Message-ID: On Sat, Aug 14, 2021 at 06:53:08PM +0200, Andreas Abel wrote: > readVersion :: String -> Version > readVersion = read > > main :: IO () > main = print $ readVersion "8.10.5" Perhaps this is close to what you want: λ> import Data.Version λ> import Text.ParserCombinators.ReadP λ> foldr (const . Just) Nothing $ readP_to_S (parseVersion <* eof) "8.10.5" Just (Version {versionBranch = [8,10,5], versionTags = []},"") λ> foldr (const . Just) Nothing $ readP_to_S (parseVersion <* eof) "8.10.X" Nothing λ> foldr (const . Just) Nothing $ readP_to_S (parseVersion <* eof) "8.10.5-foo-bar" Just (Version {versionBranch = [8,10,5], versionTags = ["foo","bar"]},"") [ foldr (const . Just) Nothing == listToMaybe) ] -- Viktor. From callan.mcgill at gmail.com Mon Aug 16 12:08:31 2021 From: callan.mcgill at gmail.com (Callan McGill) Date: Mon, 16 Aug 2021 08:08:31 -0400 Subject: Lookup variant for IntMap Message-ID: Hi all, I recently noticed that lookup for IntMap favours searches that can fast-fail - if instead we are in a situation where lookups are mostly successful, then this can be wasteful (see this issue for details: https://github.com/haskell/containers/issues/794). Since both versions are useful, it would be best to offer users both variants. I wondered if people on this list had any suggestions for a name for the new function? David Feuer also wondered which of these two behaviours should be the default. My inclination is for it to be the current version which fails faster (this also guarantees no unfortunate regressions) but it would be useful to run more substantial real-world benchmarks to figure that out (if anyone has any suggestions then do let me know). Best wishes, Callan -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.thaddeus at gmail.com Mon Aug 16 14:49:09 2021 From: andrew.thaddeus at gmail.com (Andrew Martin) Date: Mon, 16 Aug 2021 10:49:09 -0400 Subject: Lookup variant for IntMap In-Reply-To: References: Message-ID: This is an interesting question. As a general rule, I tend to write code that is optimized for the success case, but usually, I'm thinking about things like parsing, where failure is extremely uncommon. With an ordered map, there are certainly situations where failure is the more common case. However, one important question is: What are you going to do if the element is not present? One possibility is to add the missing value. But if you're doing that, then you chose the wrong operation to begin with. Alter (known as upsert in other ecosystems) outperforms the combination of lookup and insert, or at least it should. That's all I can think of at the moment on this topic. It would interesting to see if someone is aware of a situation where the current behavior is advantageous. On Mon, Aug 16, 2021 at 8:13 AM Callan McGill wrote: > Hi all, > > I recently noticed that lookup for IntMap favours searches that can > fast-fail - if instead we are in a situation where lookups are mostly > successful, then this can be wasteful (see this issue for details: > https://github.com/haskell/containers/issues/794). Since both versions > are useful, it would be best to offer users both variants. > > I wondered if people on this list had any suggestions for a name for the > new function? David Feuer also wondered which of these two behaviours > should be the default. My inclination is for it to be the current version > which fails faster (this also guarantees no unfortunate regressions) but it > would be useful to run more substantial real-world benchmarks to figure > that out (if anyone has any suggestions then do let me know). > > Best wishes, > Callan > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -- -Andrew Thaddeus Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmaessen at alum.mit.edu Mon Aug 16 15:04:25 2021 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Mon, 16 Aug 2021 11:04:25 -0400 Subject: Lookup variant for IntMap In-Reply-To: References: Message-ID: Reading the issue and the benchmarks, it seems like the right call here might be to make the "throws error" version the one that defers the failure check, and to use a similar algorithm for update (which must search to the leaf in any case). So (!) uses the new algorithm, as do alterF and family. lookup, member, and findWithDefault retain the old algorithm. That does leave an opening for an expected-to-hit lookup that can still miss. I'd suggest having an alternative only to lookup, rather than repeating the whole suite of lookup-, member-, and find-like things. It looks like the benchmarks are manipulating quite large IntMaps? I wonder how things look for smaller, shallower maps where fail-late tends to dominate. I use maps-with-miss all the time, but seldom with (say) millions of elements. -Jan-Willem Maessen On Mon, Aug 16, 2021 at 8:12 AM Callan McGill wrote: > Hi all, > > I recently noticed that lookup for IntMap favours searches that can > fast-fail - if instead we are in a situation where lookups are mostly > successful, then this can be wasteful (see this issue for details: > https://github.com/haskell/containers/issues/794). Since both versions > are useful, it would be best to offer users both variants. > > I wondered if people on this list had any suggestions for a name for the > new function? David Feuer also wondered which of these two behaviours > should be the default. My inclination is for it to be the current version > which fails faster (this also guarantees no unfortunate regressions) but it > would be useful to run more substantial real-world benchmarks to figure > that out (if anyone has any suggestions then do let me know). > > Best wishes, > Callan > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.jakobi at googlemail.com Mon Aug 16 18:28:16 2021 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Mon, 16 Aug 2021 20:28:16 +0200 Subject: Lookup variant for IntMap In-Reply-To: References: Message-ID: Am Mo., 16. Aug. 2021 um 17:06 Uhr schrieb Jan-Willem Maessen : > > Reading the issue and the benchmarks, it seems like the right call here might be to make the "throws error" version the one that defers the failure check, and to use a similar algorithm for update (which must search to the leaf in any case). update can terminate fast too. See the nomatch case in updateWithKey: https://hackage.haskell.org/package/containers-0.6.5.1/docs/src/Data.IntMap.Internal.html#update From hasufell at posteo.de Mon Aug 16 18:57:33 2021 From: hasufell at posteo.de (Julian Ospald) Date: Mon, 16 Aug 2021 18:57:33 +0000 Subject: Moving the abstract filepath proposal forward Message-ID: <20210816185733.ool6n6xuchdmgpgp@localhost.localdomain> Hi, as was discussed some time ago, I'd like to move the AFPP forward: https://discourse.haskell.org/t/reviving-the-abstract-filepath-proposal-afpp-in-user-space/2344 If you need a refresher on the original proposal, have a look here: https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/abstract-file-path The idea was to implement it in user-space first. I think I have now assembled a version that should withstand initial review: * code: https://github.com/hasufell/abstract-filepath * rendered docs: https://files.hasufell.de/jule/abstract-filepath/ What changed wrt the original proposal is this: 1. created a `OsString` newtype and `AbstractFilePath` is just a type synonym to it (this is somewhat similar to how rust does it... filepaths are not the only thing that syscalls expect in UTF16 on windows) 2. added `OsWord` as well The types are all here: * https://files.hasufell.de/jule/abstract-filepath/AFP-OsString-Internal-Types.html * https://files.hasufell.de/jule/abstract-filepath/AFP-AbstractFilePath-Internal-Types.html How to move forward? 1. get actual code reviews... rather on the issue tracker than here: https://github.com/hasufell/abstract-filepath/pull/4/files 2. discuss whether some of the ByteString stuff (we operate mostly on ShortByteString here and I added lots of new functions) should be fed back into the 'bytestring' package 3. discuss how to split the package (probably need one only for the types, so e.g. core libraries could have a light import) 4. start writing patches for unix and Win32 Please, help and comments appreciated. This can only be done as a combined effort. The CLC, last time I asked, was behind this approach. Cheers, Julian From samuelrivas at gmail.com Tue Aug 17 08:28:52 2021 From: samuelrivas at gmail.com (Samuel) Date: Tue, 17 Aug 2021 10:28:52 +0200 Subject: readline library Message-ID: Hi, The readline library sets libraries at haskell.org as maintainer, so trying to find if anyone is maintaining it in this list. http://hackage.haskell.org/package/readline-1.0.3.0 The library doesn't build properly with Cabal 3, though its cabal file doesn't limit it to Cabal 2. That makes it fail to build in the latest nix packages release. You can see the details in this pull request: https://github.com/NixOS/nixpkgs/pull/111985. This patch seems to be enough to make the library compile again, but I haven't found anywhere to submit it to fix the library code itself. At the moment the patch lives in the nixpkgs repository: https://github.com/samuelrivas/nixpkgs/blob/30eec30626bd7b8c592dab572e74443627d88a1c/pkgs/development/haskell-modules/patches/readline-fix-for-cabal-3.patch Is there any upstream copy of the readline library where I can pull request this patch? Thanks! -- Samuel From simon.jakobi at googlemail.com Tue Aug 17 14:16:00 2021 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Tue, 17 Aug 2021 16:16:00 +0200 Subject: readline library In-Reply-To: References: Message-ID: CC'ing Jan Stolarek who had uploaded the latest releases. Am Di., 17. Aug. 2021 um 10:30 Uhr schrieb Samuel : > > Hi, > > The readline library sets libraries at haskell.org as maintainer, so > trying to find if anyone is maintaining it in this list. > > http://hackage.haskell.org/package/readline-1.0.3.0 > > The library doesn't build properly with Cabal 3, though its cabal file doesn't > limit it to Cabal 2. That makes it fail to build in the latest nix > packages release. You can see the details in this pull request: > > https://github.com/NixOS/nixpkgs/pull/111985. > > This patch seems to be enough to make the library compile again, but I > haven't found anywhere > to submit it to fix the library code itself. At the moment the patch > lives in the nixpkgs repository: > > https://github.com/samuelrivas/nixpkgs/blob/30eec30626bd7b8c592dab572e74443627d88a1c/pkgs/development/haskell-modules/patches/readline-fix-for-cabal-3.patch > > Is there any upstream copy of the readline library where I can pull > request this patch? > > Thanks! > > -- > Samuel > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From carter.schonwald at gmail.com Thu Aug 19 23:08:38 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 19 Aug 2021 16:08:38 -0700 Subject: FYI Message-ID: This seems to have not been passed along to this yet … https://discourse.haskell.org/t/state-of-the-core-libraries-committee-update/2911 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sun Aug 22 01:44:06 2021 From: david.feuer at gmail.com (David Feuer) Date: Sat, 21 Aug 2021 21:44:06 -0400 Subject: Proposal: add generic helpers for MonadZip Message-ID: We can offer generic helpers for writing MonadZip instances: genericmzipWith :: (Generic1 m, GMonadZip (Rep1 m)) => (a -> b -> c) -> m a -> m b -> m c genericmzipWith f m n = to1 $ gmzipWith f (from1 m) (from1 n) genericmunzip :: (Generic1 m, GMonadZip (Rep1 m)) => m (a, b) -> (m a, m b) genericmunzip m = case gmunzip (from1 m) of (r1, r2) -> (to1 r1, to1 r2) These can be used with appropriate product types (there's no way to zip sums generically). I propose adding these to Control.Monad.Zip. The GMonadZip class and its instances are below. class GMonadZip f where gmzipWith :: (a -> b -> c) -> f a -> f b -> f c gmunzip :: f (a, b) -> (f a, f b) instance MonadZip f => GMonadZip (Rec1 f) where gmzipWith f (Rec1 fa) (Rec1 fb) = Rec1 (mzipWith f fa fb) gmunzip (Rec1 fab) = (Rec1 fa, Rec1 fb) where -- We want to be lazy here, because this might actually -- be recursive. We do a lot of NOINLINE to get selector -- thunks to avoid space leaks. {-# NOINLINE mufab #-} {-# NOINLINE fa #-} {-# NOINLINE fb #-} mufab = munzip fab (fa, fb) = mufab instance (Functor g, MonadZip f, GMonadZip g) => GMonadZip (f :.: g) where gmzipWith f (Comp1 fga1) (Comp1 fga2) = Comp1 $ mzipWith (gmzipWith f) fga1 fga2 gmunzip (Comp1 fgc) = case munzip . fmap gmunzip $ fgc of (p, q) -> (Comp1 p, Comp1 q) -- | @since 4.9.0.0 instance GMonadZip U1 where gmzipWith _ _ _ = U1 gmunzip _ = (U1, U1) -- | @since 4.9.0.0 instance GMonadZip Par1 where gmzipWith = coerce gmunzip = coerce -- | @since 4.9.0.0 deriving instance GMonadZip f => GMonadZip (M1 i c f) -- | @since 4.9.0.0 instance (GMonadZip f, GMonadZip g) => GMonadZip (f :*: g) where gmzipWith f (x1 :*: y1) (x2 :*: y2) = gmzipWith f x1 x2 :*: gmzipWith f y1 y2 -- Why don't we need to be lazy in this munzip? If we're working with -- Rep1, then laziness will be added by the Rec1 instance. If we're working -- with Rep, then we can't have any K1s because K1 isn't an instance of -- Monad, let alone MonadZip! gmunzip (fab :*: gab) | (fa, fb) <- gmunzip fab , (ga, gb) <- gmunzip gab = (fa :*: ga, fb :*: gb) From david.feuer at gmail.com Sun Aug 22 02:00:06 2021 From: david.feuer at gmail.com (David Feuer) Date: Sat, 21 Aug 2021 22:00:06 -0400 Subject: Proposal: add generic helpers for MonadZip In-Reply-To: References: Message-ID: While we can't *zip* sums generically, we can *unzip* them. Here's a rewrite: genericmzipWith :: (Generic1 m, GMonadZip (Rep1 m)) => (a -> b -> c) -> m a -> m b -> m c genericmzipWith f m1 m2 = to1 $ gmzipWith f (from1 m1) (from1 m2) genericmunzip :: (Generic1 m, GMonadUnzip (Rep1 m)) => m (a, b) -> (m a, m b) genericmunzip m = case gmunzip (from1 m) of (p, q) -> (to1 p, to1 q) class GMonadZip f where gmzipWith :: (a -> b -> c) -> f a -> f b -> f c class GMonadUnzip f where gmunzip :: f (a, b) -> (f a, f b) instance MonadZip f => GMonadZip (Rec1 f) where gmzipWith f (Rec1 fa) (Rec1 fb) = Rec1 (mzipWith f fa fb) instance MonadZip f => GMonadUnzip (Rec1 f) where gmunzip (Rec1 fab) = (Rec1 fa, Rec1 fb) where -- We want to be lazy here, because this might actually -- be recursive. We do a lot of NOINLINE to get selector -- thunks to avoid space leaks. {-# NOINLINE mufab #-} {-# NOINLINE fa #-} {-# NOINLINE fb #-} mufab = munzip fab (fa, fb) = mufab nstance (MonadZip f, GMonadZip g) => GMonadZip (f :.: g) where gmzipWith f (Comp1 fga1) (Comp1 fga2) = Comp1 $ mzipWith (gmzipWith f) fga1 fga2 instance (Functor g, MonadZip f, GMonadUnzip g) => GMonadUnzip (f :.: g) where gmunzip (Comp1 fgc) = case munzip . fmap gmunzip $ fgc of (p, q) -> (Comp1 p, Comp1 q) instance GMonadZip U1 where gmzipWith _ _ _ = U1 instance GMonadUnzip U1 where gmunzip _ = (U1, U1) instance GMonadZip Par1 where gmzipWith = coerce instance GMonadUnzip Par1 where gmunzip = coerce deriving instance GMonadZip f => GMonadZip (M1 i c f) deriving instance GMonadUnzip f => GMonadUnzip (M1 i c f) instance (GMonadZip f, GMonadZip g) => GMonadZip (f :*: g) where gmzipWith f (x1 :*: y1) (x2 :*: y2) = gmzipWith f x1 x2 :*: gmzipWith f y1 y2 instance (GMonadUnzip f, GMonadUnzip g) => GMonadUnzip (f :*: g) where -- Why don't we need to be lazy in this munzip? If we're working with -- Rep1, then laziness will be added by the Rec1 instance. If we're working -- with Rep, then we can't have any K1s because K1 isn't an instance of -- Monad, let alone MonadZip! gmunzip (fab :*: gab) | (fa, fb) <- gmunzip fab , (ga, gb) <- gmunzip gab = (fa :*: ga, fb :*: gb) instance (GMonadUnzip f, GMonadUnzip g) => GMonadUnzip (f :+: g) where gmunzip (L1 x) = case gmunzip x of (l, r) -> (L1 l, L1 r) gmunzip (R1 x) = case gmunzip x of (l, r) -> (R1 l, R1 r) On Sat, Aug 21, 2021 at 9:44 PM David Feuer wrote: > > We can offer generic helpers for writing MonadZip instances: > > genericmzipWith :: (Generic1 m, GMonadZip (Rep1 m)) => (a -> b -> c) > -> m a -> m b -> m c > genericmzipWith f m n = to1 $ gmzipWith f (from1 m) (from1 n) > > genericmunzip :: (Generic1 m, GMonadZip (Rep1 m)) => m (a, b) -> (m a, m b) > genericmunzip m = case gmunzip (from1 m) of (r1, r2) -> (to1 r1, to1 r2) > > These can be used with appropriate product types (there's no way to > zip sums generically). I propose adding these to Control.Monad.Zip. > The GMonadZip class and its instances are below. > > class GMonadZip f where > gmzipWith :: (a -> b -> c) -> f a -> f b -> f c > gmunzip :: f (a, b) -> (f a, f b) > > instance MonadZip f => GMonadZip (Rec1 f) where > gmzipWith f (Rec1 fa) (Rec1 fb) = Rec1 (mzipWith f fa fb) > gmunzip (Rec1 fab) = (Rec1 fa, Rec1 fb) > where > -- We want to be lazy here, because this might actually > -- be recursive. We do a lot of NOINLINE to get selector > -- thunks to avoid space leaks. > {-# NOINLINE mufab #-} > {-# NOINLINE fa #-} > {-# NOINLINE fb #-} > mufab = munzip fab > (fa, fb) = mufab > > instance (Functor g, MonadZip f, GMonadZip g) => GMonadZip (f :.: g) where > gmzipWith f (Comp1 fga1) (Comp1 fga2) = Comp1 $ mzipWith (gmzipWith > f) fga1 fga2 > gmunzip (Comp1 fgc) = case munzip . fmap gmunzip $ fgc of > (p, q) -> (Comp1 p, Comp1 q) > > -- | @since 4.9.0.0 > instance GMonadZip U1 where > gmzipWith _ _ _ = U1 > gmunzip _ = (U1, U1) > > -- | @since 4.9.0.0 > instance GMonadZip Par1 where > gmzipWith = coerce > gmunzip = coerce > > -- | @since 4.9.0.0 > deriving instance GMonadZip f => GMonadZip (M1 i c f) > > -- | @since 4.9.0.0 > instance (GMonadZip f, GMonadZip g) => GMonadZip (f :*: g) where > gmzipWith f (x1 :*: y1) (x2 :*: y2) = gmzipWith f x1 x2 :*: > gmzipWith f y1 y2 > -- Why don't we need to be lazy in this munzip? If we're working with > -- Rep1, then laziness will be added by the Rec1 instance. If we're working > -- with Rep, then we can't have any K1s because K1 isn't an instance of > -- Monad, let alone MonadZip! > gmunzip (fab :*: gab) > | (fa, fb) <- gmunzip fab > , (ga, gb) <- gmunzip gab > = (fa :*: ga, fb :*: gb) From david.feuer at gmail.com Mon Aug 23 01:45:32 2021 From: david.feuer at gmail.com (David Feuer) Date: Sun, 22 Aug 2021 21:45:32 -0400 Subject: [ANNOUNCE] GHC 9.2.1-rc1 now available In-Reply-To: References: <87wnodm9dq.fsf@smart-cactus.org> Message-ID: Sorry, I was unclear. I want it re-exported from Data.Tuple, so I don't need to import ghc-prim:GHC.Tuple. I proposed this on the libraries list last year, and the two people who responded agreed. On Sun, Aug 22, 2021, 9:37 PM Viktor Dukhovni wrote: > > On 22 Aug 2021, at 8:14 pm, David Feuer wrote: > > > > One more question: is Solo exported from Data.Tuple yet, or do we still > have to depend on ghc-prim and import it from GHC.Magic? It would be really > nice to have that fixed by release, and it's so tiny. > > The GHC.Tuple modules (from ghc-prim) are identical in the HEAD and ghc-9.2 > branches. With HEAD I see: > > $ ghci > GHCi, version 9.3.20210809: https://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /usr/home/viktor/.ghc/ghci.conf > λ> import GHC.Tuple > λ> :info Solo > type Solo :: * -> * > data Solo a = Solo a > -- Defined in ‘GHC.Tuple’ > instance Applicative Solo -- Defined in ‘GHC.Base’ > instance Functor Solo -- Defined in ‘GHC.Base’ > instance Monad Solo -- Defined in ‘GHC.Base’ > instance Monoid a => Monoid (Solo a) -- Defined in ‘GHC.Base’ > instance Semigroup a => Semigroup (Solo a) -- Defined in ‘GHC.Base’ > instance Show a => Show (Solo a) -- Defined in ‘GHC.Show’ > instance Read a => Read (Solo a) -- Defined in ‘GHC.Read’ > instance Foldable Solo -- Defined in ‘Data.Foldable’ > instance Traversable Solo -- Defined in ‘Data.Traversable’ > > -- > Viktor. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Mon Aug 23 02:10:13 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sun, 22 Aug 2021 22:10:13 -0400 Subject: [ANNOUNCE] GHC 9.2.1-rc1 now available In-Reply-To: References: <87wnodm9dq.fsf@smart-cactus.org> Message-ID: <93AB1F32-FCD1-46F9-8A26-076065C61A90@dukhovni.org> > On 22 Aug 2021, at 9:45 pm, David Feuer wrote: > > Sorry, I was unclear. I want it re-exported from Data.Tuple, so I don't need to import ghc-prim:GHC.Tuple. I proposed this on the libraries list last year, and the two people who responded agreed. Clear now. This appears to not have been done yet in either HEAD or 9.2. Care to open an MR? -- Viktor. From chessai1996 at gmail.com Mon Aug 23 02:25:29 2021 From: chessai1996 at gmail.com (chessai) Date: Sun, 22 Aug 2021 21:25:29 -0500 Subject: [ANNOUNCE] GHC 9.2.1-rc1 now available In-Reply-To: <93AB1F32-FCD1-46F9-8A26-076065C61A90@dukhovni.org> References: <87wnodm9dq.fsf@smart-cactus.org> <93AB1F32-FCD1-46F9-8A26-076065C61A90@dukhovni.org> Message-ID: If you opened an MR to add Solo to Data.Tuple, I would likely accept it. Please make sure to ping @core-libraries. Thanks On Sun, Aug 22, 2021, 21:11 Viktor Dukhovni wrote: > > > > On 22 Aug 2021, at 9:45 pm, David Feuer wrote: > > > > Sorry, I was unclear. I want it re-exported from Data.Tuple, so I don't > need to import ghc-prim:GHC.Tuple. I proposed this on the libraries list > last year, and the two people who responded agreed. > > Clear now. This appears to not have been done yet in either HEAD > or 9.2. Care to open an MR? > > -- > Viktor. > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Mon Aug 23 02:25:32 2021 From: david.feuer at gmail.com (David Feuer) Date: Sun, 22 Aug 2021 22:25:32 -0400 Subject: [ANNOUNCE] GHC 9.2.1-rc1 now available In-Reply-To: <93AB1F32-FCD1-46F9-8A26-076065C61A90@dukhovni.org> References: <87wnodm9dq.fsf@smart-cactus.org> <93AB1F32-FCD1-46F9-8A26-076065C61A90@dukhovni.org> Message-ID: Just did it :) On Sun, Aug 22, 2021, 10:11 PM Viktor Dukhovni wrote: > > > > On 22 Aug 2021, at 9:45 pm, David Feuer wrote: > > > > Sorry, I was unclear. I want it re-exported from Data.Tuple, so I don't > need to import ghc-prim:GHC.Tuple. I proposed this on the libraries list > last year, and the two people who responded agreed. > > Clear now. This appears to not have been done yet in either HEAD > or 9.2. Care to open an MR? > > -- > Viktor. > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Mon Aug 23 02:32:42 2021 From: david.feuer at gmail.com (David Feuer) Date: Sun, 22 Aug 2021 22:32:42 -0400 Subject: [ANNOUNCE] GHC 9.2.1-rc1 now available In-Reply-To: References: <87wnodm9dq.fsf@smart-cactus.org> <93AB1F32-FCD1-46F9-8A26-076065C61A90@dukhovni.org> Message-ID: Done. Need to know what GHC/base version changelog to stick it in. On Sun, Aug 22, 2021, 10:26 PM chessai wrote: > If you opened an MR to add Solo to Data.Tuple, I would likely accept it. > Please make sure to ping @core-libraries. > > Thanks > > On Sun, Aug 22, 2021, 21:11 Viktor Dukhovni > wrote: > >> >> >> > On 22 Aug 2021, at 9:45 pm, David Feuer wrote: >> > >> > Sorry, I was unclear. I want it re-exported from Data.Tuple, so I don't >> need to import ghc-prim:GHC.Tuple. I proposed this on the libraries list >> last year, and the two people who responded agreed. >> >> Clear now. This appears to not have been done yet in either HEAD >> or 9.2. Care to open an MR? >> >> -- >> Viktor. >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hecate at glitchbra.in Fri Aug 27 19:46:07 2021 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Fri, 27 Aug 2021 21:46:07 +0200 Subject: [Call for reviewers] Switch `text`'s internal representation to UTF-8 Message-ID: Hello everyone, After tremendous efforts, the pull request to switch `text`'s internal representation to UTF-8 is here, and unsurprisingly this is a titan's work. It lives here: https://github.com/haskell/text/pull/365 We are sending out a call for reviewers, as this is a cornerstone of our ecosystem. The performance gains from this PR are huge and I would like to ensure we can have a multitude of eyes to take a look. I wish to express my thanks to all of you. This is definitely the kind of advances that will make Haskell a stronger language for the times to come. Cheers, Hécate. -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD