From jmct at jmct.cc Wed Sep 7 00:08:32 2016 From: jmct at jmct.cc (=?UTF-8?Q?Jos=C3=A9_Manuel_Calder=C3=B3n_Trilla?=) Date: Tue, 6 Sep 2016 20:08:32 -0400 Subject: Meet up at ICFP? Message-ID: Hello Haskell Prime, On IRC Andres Löh suggested that we have a haskell prime gathering that coincides with ICFP. I told him that I'd take on organizing it, and now that we're only a few weeks away it's probably time to do so. First and foremost, the main purpose of this would be to meet each other, put faces to names, and get a sense of who is interested in what. We aren't trying to finalise any decisions via back-room discussions :) So with that in mind, if you're interested, please email me with your availability. Non-committee members are welcome to email me as well. I'll find the time that works for most and sort something out. There are a few ICFP-wide constraints: Monday Sept. 19th, 18:30 - 20:30: Welcome reception and student-research competition Tuesday Sept. 20th, 19:00 -21:00: Reception and Banquet Thursday Sept. 22nd, 18:30 - 20:30: Industrial Reception If there are any other constraints that you know of (PC meetings, Steering Committee meetings, etc) let me know. Cheers, José From jmct at jmct.cc Wed Sep 14 18:17:02 2016 From: jmct at jmct.cc (=?UTF-8?Q?Jos=C3=A9_Manuel_Calder=C3=B3n_Trilla?=) Date: Wed, 14 Sep 2016 14:17:02 -0400 Subject: Meet up at ICFP? In-Reply-To: References: Message-ID: Hello again, Thanks for everyone that emailed me with their constraints, and those that let me know they can't make it but they have specific concerns, I'll make sure those are heard. Luckily from a constraint point of view people seem pretty flexible. Richard Eisenberg suggest that lunch on Monday might be a good time. Are people okay with that? I can reach out to the local organisers to see if they can set aside a table/space for those of us that want to meet. Lunch seems like a good idea as that leaves the evenings open for impromptu plans that tend to come up at ICFP. Another time that works for everyone is Wednesday evening. I'm happy to sort something out if that's what people prefer. For now let's plan on Monday lunch and if there's a big conflict we're change course. Richard has also volunteered to act as secretary for the meeting so that the minutes of the meeting can be posted. Thanks Richard! Thanks everyone, Jose On Tue, Sep 6, 2016 at 8:08 PM, José Manuel Calderón Trilla wrote: > Hello Haskell Prime, > > On IRC Andres Löh suggested that we have a haskell prime gathering > that coincides with ICFP. I told him that I'd take on organizing it, > and now that we're only a few weeks away it's probably time to do so. > > First and foremost, the main purpose of this would be to meet each > other, put faces to names, and get a sense of who is interested in > what. We aren't trying to finalise any decisions via back-room > discussions :) > > So with that in mind, if you're interested, please email me with your > availability. Non-committee members are welcome to email me as well. > I'll find the time that works for most and sort something out. > > There are a few ICFP-wide constraints: > > Monday Sept. 19th, 18:30 - 20:30: Welcome reception and > student-research competition > Tuesday Sept. 20th, 19:00 -21:00: Reception and Banquet > Thursday Sept. 22nd, 18:30 - 20:30: Industrial Reception > > If there are any other constraints that you know of (PC meetings, > Steering Committee meetings, etc) let me know. > > Cheers, > > José From mblazevic at stilo.com Fri Sep 16 13:51:24 2016 From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=) Date: Fri, 16 Sep 2016 09:51:24 -0400 Subject: Meet up at ICFP? In-Reply-To: References: Message-ID: <7ec94337-ae8b-086e-b8dc-a5810ab85a3e@stilo.com> On 2016-09-14 02:17 PM, José Manuel Calderón Trilla wrote: > Richard has also volunteered to act as secretary for the meeting so > that the minutes of the meeting can be posted. Thanks Richard! Thanks from all of us who can't attend as well. Please do post the minutes! From carter.schonwald at gmail.com Mon Sep 19 01:16:42 2016 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 18 Sep 2016 21:16:42 -0400 Subject: Meet up at ICFP? In-Reply-To: <7ec94337-ae8b-086e-b8dc-a5810ab85a3e@stilo.com> References: <7ec94337-ae8b-086e-b8dc-a5810ab85a3e@stilo.com> Message-ID: yeah, i couldn't make it too :( On Fri, Sep 16, 2016 at 9:51 AM, Mario Blažević wrote: > On 2016-09-14 02:17 PM, José Manuel Calderón Trilla wrote: > >> Richard has also volunteered to act as secretary for the meeting so >> that the minutes of the meeting can be posted. Thanks Richard! >> > > Thanks from all of us who can't attend as well. Please do post the minutes! > > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Henrik.Nilsson at nottingham.ac.uk Mon Sep 19 06:40:27 2016 From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson) Date: Mon, 19 Sep 2016 06:40:27 +0000 Subject: Meet up at ICFP? In-Reply-To: References: <7ec94337-ae8b-086e-b8dc-a5810ab85a3e@stilo.com>, Message-ID: <5lnicc3w0quq16gihjb7ejp5.1474267220825@email.android.com> Dear all, Same here. I will unfortunately not be attending ICFP. /Henrik Henrik Nilsson School of Computer Science The University of Nottingham nhn at cs.nott.ac.uk -------- Original message -------- From: Carter Schonwald Date:2016/09/19 02:17 (GMT+00:00) To: Mario Blažević Cc: "haskell-prime at haskell.org Prime" Subject: Re: Meet up at ICFP? yeah, i couldn't make it too :( On Fri, Sep 16, 2016 at 9:51 AM, Mario Blažević > wrote: On 2016-09-14 02:17 PM, José Manuel Calderón Trilla wrote: Richard has also volunteered to act as secretary for the meeting so that the minutes of the meeting can be posted. Thanks Richard! Thanks from all of us who can't attend as well. Please do post the minutes! _______________________________________________ Haskell-prime mailing list Haskell-prime at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dluposchainsky at googlemail.com Thu Sep 22 16:33:54 2016 From: dluposchainsky at googlemail.com (David Luposchainsky) Date: Thu, 22 Sep 2016 18:33:54 +0200 Subject: New Github features and Haskell Prime Message-ID: <1d873b94-f424-24e7-a9b1-d8ddd6a00355@gmail.com> Hello prime people, Github recently added a board-style overview over tickets and small notes. I think this is a great addition, and converted all current PRs to board items. There is no shortage of things to be considered for Haskell Prime, and I find it hard to think of them all. For things I’m somewhat interested in seeing a proposal for, I created notes that are not yet tickets, but serve as a reminder to consider them at some point. I’d like to invite you all to add your language extensions and ideas to the board in the pre-proposal column. Even if you don’t have the time to write a proposal, someone else might see the note and decide to do so instead. See you at https://github.com/haskell/rfcs/projects/1 Greetings, David/quchen -- My GPG keys: https://keybase.io/quchen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From m.farkasdyck at gmail.com Thu Sep 22 17:43:12 2016 From: m.farkasdyck at gmail.com (M Farkas-Dyck) Date: Thu, 22 Sep 2016 09:43:12 -0800 Subject: New Github features and Haskell Prime In-Reply-To: <1d873b94-f424-24e7-a9b1-d8ddd6a00355@gmail.com> References: <1d873b94-f424-24e7-a9b1-d8ddd6a00355@gmail.com> Message-ID: I see we have a "Last call" column. What are its semantics? What are the criteria for moving an RFC into it? Once there, can the RFC be moved back out? Has it a time limit when an RFC there must be either merged or closed? How shall we choose whether to merge or close? If no one has an idea yet, i propose this: • A Committee member can move to nominate an RFC by making a comment to that effect. If no comments have been made on the RFC since, another member may then move the RFC to "Last call". • Once in "Last call", an RFC remains for 1 week while further comments can be made and committee members cast votes for either "Merge" or "Close". Open question: shall we vote openly in the comments or by some other system TBD? • At the end of the voting period, if a majority of the committee (not merely of those who voted) votes to merge or close, we do so; else we move the RFC back to "In discussion". I formulated this procedure so no one member could push an agenda unilaterally, but to break the stall in progress i have been feeling here. Alternative proposals welcome. From dluposchainsky at googlemail.com Thu Sep 22 21:08:14 2016 From: dluposchainsky at googlemail.com (David Luposchainsky) Date: Thu, 22 Sep 2016 23:08:14 +0200 Subject: New Github features and Haskell Prime In-Reply-To: References: <1d873b94-f424-24e7-a9b1-d8ddd6a00355@gmail.com> Message-ID: I did not plan this out too much. I would say let's use common sense rather than setting up processes. The columns are to give viewers an overview for our open process. Anyway, here's the gist behind the columns when I created them: Pre-proposed is for things nobody cared enough about to write the proposal. The idea is that pull requests/proposals should be created from each. Proposed is where things start being tracked as actual proposals with rst files and what have you. These are invitations for everyone to participate in the discussion. In discussion is to single out the tickets with the most traffiic for those who want to get am overview of current events. When the discussion stalls the ticket might move back a column. Last call means that, ideally, every committee member (and whoever else is interested) should do a final proof-read of the proposal. Things in this column are considered good and final by the participants in the discussion before, and if there is no objection, that's what goes into the report. The last column is to show what made it into the report pipeline for some time for our less frequent readers. Greetings, David/quchen On 22 September 2016 19:43:12 CEST, M Farkas-Dyck wrote: >I see we have a "Last call" column. What are its semantics? What are >the criteria for moving an RFC into it? Once there, can the RFC be >moved back out? Has it a time limit when an RFC there must be either >merged or closed? How shall we choose whether to merge or close? > >If no one has an idea yet, i propose this: >• A Committee member can move to nominate an RFC by making a comment >to that effect. If no comments have been made on the RFC since, >another member may then move the RFC to "Last call". >• Once in "Last call", an RFC remains for 1 week while further >comments can be made and committee members cast votes for either >"Merge" or "Close". Open question: shall we vote openly in the >comments or by some other system TBD? >• At the end of the voting period, if a majority of the committee (not >merely of those who voted) votes to merge or close, we do so; else we >move the RFC back to "In discussion". > >I formulated this procedure so no one member could push an agenda >unilaterally, but to break the stall in progress i have been feeling >here. Alternative proposals welcome. -- Sent from my cellphone. Please excuse my brevity. From rae at cs.brynmawr.edu Mon Sep 26 21:05:05 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 26 Sep 2016 17:05:05 -0400 Subject: New Github features and Haskell Prime In-Reply-To: References: <1d873b94-f424-24e7-a9b1-d8ddd6a00355@gmail.com> Message-ID: <5BCA9671-EA13-4050-BD3C-3A9B8A16268A@cs.brynmawr.edu> > On Sep 22, 2016, at 5:08 PM, David Luposchainsky via Haskell-prime wrote: > > I did not plan this out too much. I would say let's use common sense rather than setting up processes. The columns are to give viewers an overview for our open process. > I think having a formal process aids in transparency, something that some in our community feel is lacking. I therefore think that we should indeed have a formal process. If the process ends up tying our hands behind our back, then we change it! I like the process suggested by M. Richard From mf at zerobuzz.net Tue Sep 27 00:47:06 2016 From: mf at zerobuzz.net (Matthias Fischmann) Date: Tue, 27 Sep 2016 09:47:06 +0900 Subject: New Github features and Haskell Prime In-Reply-To: <5BCA9671-EA13-4050-BD3C-3A9B8A16268A@cs.brynmawr.edu> References: <1d873b94-f424-24e7-a9b1-d8ddd6a00355@gmail.com> <5BCA9671-EA13-4050-BD3C-3A9B8A16268A@cs.brynmawr.edu> Message-ID: <20160927004706.GI18760@lig> On Mon, Sep 26, 2016 at 05:05:05PM -0400, Richard Eisenberg wrote: > Date: Mon, 26 Sep 2016 17:05:05 -0400 > From: Richard Eisenberg > To: David Luposchainsky > Cc: M Farkas-Dyck , Haskell-prime Mailing List > > Subject: Re: New Github features and Haskell Prime > > > > On Sep 22, 2016, at 5:08 PM, David Luposchainsky via Haskell-prime wrote: > > > > I did not plan this out too much. I would say let's use common sense rather than setting up processes. The columns are to give viewers an overview for our open process. > > > > I think having a formal process aids in transparency, something that some in our community feel is lacking. I therefore think that we should indeed have a formal process. If the process ends up tying our hands behind our back, then we change it! > > I like the process suggested by M. i agree, and would like to propose an independent ratification process. the following is all from me listening to people who have an intimidating amout of experience with this. icfp is great! (-: everybody can sign up to the ratification process with email and a few lines on who they are and why they care. once the standard is finalized, everybody gets to vote. nay-voters have to (are allowed to?) submit change requests that would compell them to vote yay. if the proposal gets 70% yays it becomes law, and nobody gets to complain that they haven't been asked. if the proposal falls short of the 70%, the change requests are reviewed and negotiated into a new proposal. this is hoped to take less effort than the original draft, but still enough to discourage people from frivolously opposing ideas they don't like but can live with. ratification is important for acceptance in the wider community. scheme set the bar at 50% and the standard came through with 51%, which didn't convince the nay-sayers much to embrace the it. curious how you all feel about this- m. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 205 bytes Desc: Digital signature URL: From rae at cs.brynmawr.edu Tue Sep 27 15:34:02 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 27 Sep 2016 11:34:02 -0400 Subject: New Github features and Haskell Prime In-Reply-To: <20160927004706.GI18760@lig> References: <1d873b94-f424-24e7-a9b1-d8ddd6a00355@gmail.com> <5BCA9671-EA13-4050-BD3C-3A9B8A16268A@cs.brynmawr.edu> <20160927004706.GI18760@lig> Message-ID: > On Sep 26, 2016, at 8:47 PM, Matthias Fischmann wrote: > > i agree, and would like to propose an independent ratification > process. At the risk of sounding exclusionary, I wonder what the goal of defining the committee is if the larger community can vote on each proposal. As I understood it, the committee has voting rights, while the larger community has viewing and commentary rights. We *do* most certainly value wide input. But voting is quite sensitive. In particular, you recommend a threshold of 70% before something is accepted. 70% of what? Of votes? Who is eligible to vote? And how do we publicize a vote? When is it held? What if that period of time is a big holiday in some country? Etc. It all seems to be a can of worms. Richard From rae at cs.brynmawr.edu Tue Sep 27 15:51:04 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 27 Sep 2016 11:51:04 -0400 Subject: minutes from committee meeting at ICFP References: Message-ID: <9F980153-FF5A-4802-A46D-FF6AD27DF8A4@cs.brynmawr.edu> Below are the minutes from last week’s in-person meeting at ICFP among the attending members of the Haskell Prime committee. The conversation moved swiftly, and I’ve done my best at capturing the essence of attendees’ comments. The attendees have had a week to consider these notes with no suggestions submitted; I thus consider these notes ratified. Richard ---------- Sep 19, 2016, 12:43pm JST, call to order. Present: José Trilla, Iavor Diatchki, Wren Romano, Richard Eisenberg, Simon Peyton Jones, Andres Löh, Nicolas Wu, Lennart Augustsson Convener: José Notetaker: Richard José: Let's talk about one issue and figure that one issue out. Need to maintain / start momentum. José and Iavor wrote notes about possible topics to discuss. Iavor: How do we get the process going? Want to discuss: What's in scope? What's the process for proposal? Do we need an implementation first? But that's a lot of (potentially wasted) work. Wren: We should coordinate before starting on a project to avoid duplicate effort. Simon: But that's not our problem. We need *more* people working on things. Simon: There's so much that's implemented but not formalized that we shouldn't worry about things that aren't implemented. Iavor: Not much that's uncontroversial. Iavor: Suggested uncontroversial things: TupleSections Lennart: I use TupleSections. Yes. Simon: TupleSections is too easy. What about MPTC? Wren: I'm mildly against TupleSections. Too easy to make type errors due to errant commas. Andres: TupleSections conflict with trailing commas. Some people really like trailing commas. Not overly eager for TupleSections. Prefer not to have all these syntactic special cases; favor simplicity. Iavor, Wren: They are perhaps too simple to test the process. Nick: Finish the list. We'll be quiet. Iavor: Second item: RecordWildCards, RecordPuns. I like them. Some people don't. Lennart: RecordPuns have been removed. Simon: No. They're still there. Lennart: No. I mean that they were in the standard but were removed. But now people want them back. Lennart: RecordWildCards introduce bound names with no binding site. Richard: I've been confused by this. Iavor: If you don't like these features, you don't have to use them. Simon: Haskell has always supported more than one way to do things. Like ArgumentDo. Seems overblown, but many people want them. Iavor: GADTSyntax. All: Yes. Iavor: Do we do records in GADT notation? Simon: Yes. Iavor: But the typing rules of record selectors is hard in GADTs. Simon: Yes. Richard: But that's not part of GADTSyntax. Andres: Will this include existentials? Richard: Existentials aren't much fun without the ability to pack instance dictionaries. And then we run into incoherence. I vote no. Iavor: KindSignatures. Lennart: Then we'll need a name for *. Iavor: EqualityConstraints. They can be useful in a superclass constraint. Simon: This is a sensible extension. Richard: I think EqualityConstraints will be hard to specify. Andres: Maybe if we've gotten to a lot of other things. Lennart: We'll need to have an implementation EqualityConstraints and see if it works. Iavor: MPTC. Simon: We've had them for a long time. Andres, Lennart: They're quite useful. Iavor: FlexibleInstances & FlexibleContexts Andres, Richard, Wren: These can have some weird coherence problems. Simon: If you have (Eq [a] => ...) and there is a top-level instance, now you have multiple ways potentially to solve a constraint. Andres, Simon: It's a kind of OverlappingInstances thing. Iavor: Strictly OverlappingInstances. We should have a keyword not a pragma. Restricted only to instances that overlap ones in the same module. Lennart: It should be something like instance chains, really. Iavor: GHC already orders overlapping instances. Simon: Some people use an orphan instance in a library. Iavor: That's generally wrong and hard to use correctly. Andres: Hard to have guarantees of what will happen in practice. Andres: Perhaps we should just have closed type classes. Iavor: BangPatterns. On the argument. And only on variables. Simon: It's nice on let bindings. Iavor: But that should have a different notation. Wren: The semantics are challenging on a where. José: Yes. But on a let it's ok. Simon: The Report has a description of pattern bindings in terms of rewriting to a simpler notation. It's all quite simple. Iavor: It's not how it works at the top level. Lennart: A bang on a top-level binding could happen when the program starts to run. Simon: Plausible. José: Bangs in datatype declarations leads to a `seq` only when the datatype is fully saturated. Simon: That's odd. José: The current story is less performant that it could be. Simon: It might be hard to implement. You'll have to allocate a closure for each argument. Richard: Strict let is an abomination. cf. github post. Iavor: Yes. That's why I wanted only one part of BangPatterns. Simon: The question is: What's interesting enough for people to actually do the work? Iavor: I'll do records. Richard: Once something is ruled uncontroversial, someone just has to volunteer. Andres: I've been unwilling to put in work not knowing about procedures, etc. E.g. Should every language extension be handled separately? What's the procedure. Simon: You mean: What are the steps I have to take? Wren: It's a fear of bureaucracy that's stopping you. Andres: But what really is a detailed-enough spec? The Report as is might not be enough. Lennart: But we're not going to rewrite the report. All: Agreed. Lennart: We're making a diff. Iavor: That's why we want to start with something simple. Simon: Let's start with a free-standing specification. Then people can comment on the feature. Then, integrate with the Report. Just having a diff would be a challenge for discussion. Andres: Too many things interact if we just look at diffs. Simon: Free-standing spec can have more exposition. Simon: Shall we do TupleSections? Andres: Is there any argument about how they should work? Wren: Do we need the parens around tuples, or are the commas sufficient? Many: We need the parens. Wren: I like them too. Simon: We still need a mechanism. Andres: Herbert wanted to use the GHC proposal process. ( discussion of mechanics -- generally trying to clarify GHC proposal process ) Resolved: We will all *watch* the H2020 repo. Resolved: - Start proposal on a branch. - Submit a PR from the branch to master. - Any of us can edit the branch. - We will do so in good faith. - If a substantive change needs being made, then make a PR against the PR. Iavor: We need to actually finish something before moving on. All: Yes. Finish. Andres: Changing the report is an independent phase from the proposal process. Wren: Yes. Andres: But it's not a PR. Richard: Do we have the source for H2010? All: Yes. Herbert may have put it in. Simon: Can we have very clear github instructions? Iavor: Yes. I volunteer. José: Jurriaan wants to say: We need to remember that Haskell is an education language. José: I volunteer for TupleSections. Richard: I volunteer for GADTSyntax. Andres: I volunteer for ExistentialQuantification. Adjourn 1:36pm JST. -=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Tue Sep 27 17:10:11 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 27 Sep 2016 13:10:11 -0400 Subject: minutes from committee meeting at ICFP In-Reply-To: <878tudgtz8.fsf@ben-laptop.smart-cactus.org> References: <9F980153-FF5A-4802-A46D-FF6AD27DF8A4@cs.brynmawr.edu> <878tudgtz8.fsf@ben-laptop.smart-cactus.org> Message-ID: <58ED5837-B44F-4793-9605-B3ED8C346A27@cs.brynmawr.edu> I recall that Iavor took notes from the podium. Iavor? > On Sep 27, 2016, at 12:58 PM, Ben Gamari wrote: > > Richard Eisenberg writes: > >> Below are the minutes from last week’s in-person meeting at ICFP among >> the attending members of the Haskell Prime committee. The conversation >> moved swiftly, and I’ve done my best at capturing the essence of >> attendees’ comments. The attendees have had a week to consider these >> notes with no suggestions submitted; I thus consider these notes >> ratified. >> > Did anyone take notes from Iavor's Status of Haskell discussion during > the Symposium? There were a few points brought up there that shouldn't > be forgotten. > > Cheers, > > - Ben > From mf at zerobuzz.net Wed Sep 28 01:09:56 2016 From: mf at zerobuzz.net (Matthias Fischmann) Date: Wed, 28 Sep 2016 10:09:56 +0900 Subject: New Github features and Haskell Prime In-Reply-To: References: <1d873b94-f424-24e7-a9b1-d8ddd6a00355@gmail.com> <5BCA9671-EA13-4050-BD3C-3A9B8A16268A@cs.brynmawr.edu> <20160927004706.GI18760@lig> Message-ID: <20160928010956.GM18760@lig> On Tue, Sep 27, 2016 at 11:34:02AM -0400, Richard Eisenberg wrote: > Date: Tue, 27 Sep 2016 11:34:02 -0400 > From: Richard Eisenberg > To: Matthias Fischmann > Cc: Haskell-prime Mailing List > Subject: Re: New Github features and Haskell Prime > > > > On Sep 26, 2016, at 8:47 PM, Matthias Fischmann wrote: > > > > i agree, and would like to propose an independent ratification > > process. > > At the risk of sounding exclusionary, I wonder what the goal of defining the committee is if the larger community can vote on each proposal. As I understood it, the committee has voting rights, while the larger community has viewing and commentary rights. > > We *do* most certainly value wide input. But voting is quite sensitive. In particular, you recommend a threshold of 70% before something is accepted. 70% of what? Of votes? Who is eligible to vote? And how do we publicize a vote? When is it held? What if that period of time is a big holiday in some country? Etc. It all seems to be a can of worms. > > Richard hi richard, thanks for your reply. i don't have a strong opinion and there may well be more productive uses of the committee's time, so i'm happy to drop idea. just to be clarify for those who are still interested: i'm not suggesting we should *change* the process as much as *extend* it. once the committee has finalized haskell-prime, ask everybody (literally everybody) for a boolean. this gives the community a way to formally support the outcome in addition to people and process. and the committee has an incentive to take community feedback serious. (which, as a downside, also means it's distracting even before the finalized standard is out.) anyway. never mind. (: thanks, matthias From fa-ml at ariis.it Thu Sep 29 07:29:08 2016 From: fa-ml at ariis.it (Francesco Ariis) Date: Thu, 29 Sep 2016 09:29:08 +0200 Subject: New Github features and Haskell Prime In-Reply-To: <20160928010956.GM18760@lig> References: <1d873b94-f424-24e7-a9b1-d8ddd6a00355@gmail.com> <5BCA9671-EA13-4050-BD3C-3A9B8A16268A@cs.brynmawr.edu> <20160927004706.GI18760@lig> <20160928010956.GM18760@lig> Message-ID: <20160929072908.GA7163@casa.casa> On Wed, Sep 28, 2016 at 10:09:56AM +0900, Matthias Fischmann wrote: > just to be clarify for those who are still interested: i'm not > suggesting we should *change* the process as much as *extend* it. > once the committee has finalized haskell-prime, ask everybody > (literally everybody) for a boolean. I am pretty sure that everybody in this thread already knows, but just to clarify how Scheme proceeded: the vote was held on the mailing list and a template was given, like Name: Location: Organisation (optional): Contact (optional): Vote: Rationale: As you would expect the quality of voting (example [1]) was much much higher than "1 like = 1 monad". [1] https://web.archive.org/web/20140601050807/http://lists.scheme-reports.org/pipermail/scheme-reports/2013-April/003310.html