From cma at bitemyapp.com Wed Nov 1 21:33:34 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Wed, 1 Nov 2017 16:33:34 -0500 Subject: [ghc-steering-committee] Underscores in numbers proposal Message-ID: https://github.com/ghc-proposals/ghc-proposals/pull/76#issuecomment-339952996 This appears to have near universal approval. It's certainly a feature I've been grateful for when writing Rust code. I wasn't able to find a thread about this proposal in my email archives, so I apologize if this was redundant. Could this be moved to a decision soon? Thank you, Chris Allen From iavor.diatchki at gmail.com Wed Nov 1 22:51:46 2017 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 01 Nov 2017 22:51:46 +0000 Subject: [ghc-steering-committee] Underscores in numbers proposal In-Reply-To: References: Message-ID: I am fine with this. Related to our recent discussion: we should probably require that this be protected by a language extension, like all other literal notations. Perhaps `UnderscoreLiterals`? -Iavor PS: technically, this is not backward compatible :-) Here is an example: instance Num b => Num (a -> b) where fromInteger = const . fromInteger test :: Integer test = 1_1 where _1 = 2 Currently this evaluates to 1, but with the extension it will evaluate to 11. I don't think that any real code would be affected by this, I just had a bit of fun writing it. On Wed, Nov 1, 2017 at 2:33 PM Christopher Allen wrote: > > https://github.com/ghc-proposals/ghc-proposals/pull/76#issuecomment-339952996 > > This appears to have near universal approval. It's certainly a feature > I've been grateful for when writing Rust code. I wasn't able to find a > thread about this proposal in my email archives, so I apologize if > this was redundant. > > Could this be moved to a decision soon? > > Thank you, > Chris Allen > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Nov 1 23:00:19 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 01 Nov 2017 19:00:19 -0400 Subject: [ghc-steering-committee] Please review: underscores in numeric literals, Shepherd: Iavor Diatchki Message-ID: <1509577219.27774.3.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/76 was brought before the committee, by Takenobu Tani. I propose Iavor Diachki as the Shepherd, simply because he already responded to it. Iavor, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From chak at justtesting.org Wed Nov 1 23:57:42 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Thu, 2 Nov 2017 10:57:42 +1100 Subject: [ghc-steering-committee] Proposal: Or patterns (#43) Message-ID: <90AB84AA-2917-49E6-B4A9-DF5E634A722F@justtesting.org> Folks, I am sorry for taking a long time to get us going on this proposal. The ”Or pattern” proposal is about an extension to pattern matching: (formatted) https://github.com/osa1/ghc-proposals/blob/or_patterns/proposals/0000-or-patterns.rst (PR thread) https://github.com/ghc-proposals/ghc-proposals/pull/43 Its basic idea is simple: allow multiple alternative patterns for each alternative during pattern matching. Unfortunately, the interaction with guards and some other languages features makes it significantly less straight forward than one might initially think. I propose to accept this proposal provided we can agree to use the ”first semantics” (aka single-match semantics) — see https://github.com/osa1/ghc-proposals/blob/or_patterns/proposals/0000-or-patterns.rst#interaction-with-guards My reason for insisting on the first semantics is that it is a simple extension of the existing pattern semantics in the Report, whereas the second semantics requires a more profound, non-local change. This, in particular, also makes it easier to understand the implications of the first semantics. (Also, OCaml has made that same choice.) However, even with the first semantics, I still have one concern about this proposal. The story about the interaction with existential types is currently only partial and there is no discussion of the interaction with GADTs. It might be reasonable to ask for a complete specification of the interaction with these features before making a final determination on this proposal. Nevertheless, this proposal is quite elaborate and quite some work has gone into it. Hence, I think, we owe it the authors of the proposal to at least make a preliminary determination at this point. (In particular, if it is not going to fly regardless of how GADTs are handled, we should say so now.) Cheers, Manuel PS: It is worth noting that Swift solved the problem of deciding between the first and second semantics by choosing a syntax that avoids the ambiguity: . It is difficult to adapt this syntax to Haskell. If it where possible, I think, this would be the best solution. From marlowsd at gmail.com Thu Nov 2 08:56:10 2017 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 2 Nov 2017 08:56:10 +0000 Subject: [ghc-steering-committee] Proposal: Or patterns (#43) In-Reply-To: <90AB84AA-2917-49E6-B4A9-DF5E634A722F@justtesting.org> References: <90AB84AA-2917-49E6-B4A9-DF5E634A722F@justtesting.org> Message-ID: I'm in favour of Or patterns with the non-backtracking semantics. While '|' is the natural syntax, it does have a couple of drawbacks: - it's the same as the guard syntax, and therefore potentially confusing (it might not seem confusing to us, because we're used to parsing Haskell in our heads, but to new users I'm sure this will be confusing) - It interacts badly with this idea which I really hope we can make into a proper proposal one day: https://ghc.haskell.org/trac/ghc/wiki/ViewPatternsAlternative But '|' is also the syntax used for defining the constructor alternatives in a data type. So unless we intend to recommend GADT syntax exclusively in the future, it makes sense to use '|' for or-patterns. And I can't think of a good alternative. Cheers, Simon On 1 November 2017 at 23:57, Manuel M T Chakravarty wrote: > Folks, > > I am sorry for taking a long time to get us going on this proposal. > > The ”Or pattern” proposal is about an extension to pattern matching: > > (formatted) https://github.com/osa1/ghc-proposals/blob/or_patterns/ > proposals/0000-or-patterns.rst > (PR thread) https://github.com/ghc-proposals/ghc-proposals/pull/43 > > Its basic idea is simple: allow multiple alternative patterns for each > alternative during pattern matching. Unfortunately, the interaction with > guards and some other languages features makes it significantly less > straight forward than one might initially think. > > I propose to accept this proposal provided we can agree to use the ”first > semantics” (aka single-match semantics) — see https://github.com/osa1/ghc- > proposals/blob/or_patterns/proposals/0000-or-patterns. > rst#interaction-with-guards > > My reason for insisting on the first semantics is that it is a simple > extension of the existing pattern semantics in the Report, whereas the > second semantics requires a more profound, non-local change. This, in > particular, also makes it easier to understand the implications of the > first semantics. (Also, OCaml has made that same choice.) > > However, even with the first semantics, I still have one concern about > this proposal. The story about the interaction with existential types is > currently only partial and there is no discussion of the interaction with > GADTs. It might be reasonable to ask for a complete specification of the > interaction with these features before making a final determination on this > proposal. Nevertheless, this proposal is quite elaborate and quite some > work has gone into it. Hence, I think, we owe it the authors of the > proposal to at least make a preliminary determination at this point. (In > particular, if it is not going to fly regardless of how GADTs are handled, > we should say so now.) > > Cheers, > Manuel > > PS: It is worth noting that Swift solved the problem of deciding between > the first and second semantics by choosing a syntax that avoids the > ambiguity: Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/ > swift/grammar/switch-statement>. It is difficult to adapt this syntax to > Haskell. If it where possible, I think, this would be the best solution. > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Nov 2 13:15:32 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 2 Nov 2017 13:15:32 +0000 Subject: [ghc-steering-committee] Proposal: Or patterns (#43) In-Reply-To: <90AB84AA-2917-49E6-B4A9-DF5E634A722F@justtesting.org> References: <90AB84AA-2917-49E6-B4A9-DF5E634A722F@justtesting.org> Message-ID: In general I'm ok with this proposal. But I've just added a comment explaining some things that really need fleshing out. * The proposal should specify that in (p1 | p2) the patterns in p1 and p2 must bind the same set of variables, with the same types. Nothing else makes sense; but it is nowhere specified. * I'm concerned that the specification is incomplete. Certainly when it comes to GADTs there is some muttering about the prototype implementation, but no specification. * For GADTs it's clear to me that in (p1 | p2) the patterns p1 and p2 should bind the same set of existentials and the same set of type constraints (including class constraints), just as they must bind the same set of variables with the same types. Just write out the typing rules for patterns (which should be part of the proposal) and it'll all become clear! * I'm bothered by the stuff about view patterns, lazy patterns etc in the proposal. The point is: or-patterns has NO interaction with these patterns. We should just say that and stop! By having (quite long) sections about these features, but not (say) about tuple patterns, the implication is that there is something special to say. But there isn't. | My reason for insisting on the first semantics is that it is a simple | extension of the existing pattern semantics in the Report, whereas the | second semantics requires a more profound, non-local change. Definitely non-backtracking. The backtracking thing opens up a whole new can of worms. | quite elaborate and quite some work has gone into it. Hence, I think, | we owe it the authors of the proposal to at least make a preliminary | determination at this point. (In particular, if it is not going to fly | regardless of how GADTs are handled, we should say so now.) I agree with that... but I'd be reluctant to actually accept it into GHC unless it was fully compositional, including GADTs. So it'd be a conditional acceptance, subject to satisfactory resolution of the GADT question. I'm not sure how the implementation works out... let's see; probably fine. Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces at haskell.org] On Behalf Of Manuel M T Chakravarty | Sent: 01 November 2017 23:58 | To: ghc-steering-committee at haskell.org | Subject: [ghc-steering-committee] Proposal: Or patterns (#43) | | Folks, | | I am sorry for taking a long time to get us going on this proposal. | | The ”Or pattern” proposal is about an extension to pattern matching: | | (formatted) | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu | b.com%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000- | or- | patterns.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad54503 | 0e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177 | 4805951860&sdata=ivKxIr7%2FprF1GhUBq%2BZRxJjmKqfPq%2BNOXmbw9JPJuQ8%3D& | reserved=0 | (PR thread) | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu | b.com%2Fghc-proposals%2Fghc- | proposals%2Fpull%2F43&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be | 72ad545030e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7 | C636451774805951860&sdata=x0Xn%2BOS6mHZBWYolcaJfa5JCkbHa1pl552fNI1Swmh | w%3D&reserved=0 | | Its basic idea is simple: allow multiple alternative patterns for each | alternative during pattern matching. Unfortunately, the interaction | with guards and some other languages features makes it significantly | less straight forward than one might initially think. | | I propose to accept this proposal provided we can agree to use the | ”first semantics” (aka single-match semantics) — see | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu | b.com%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000- | or-patterns.rst%23interaction-with- | guards&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3c08 | d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480595 | 1860&sdata=Z5JJApLfReiCl0dKD2R%2Fvbs3pTZt84iEXDRhdbeVICA%3D&reserved=0 | | My reason for insisting on the first semantics is that it is a simple | extension of the existing pattern semantics in the Report, whereas the | second semantics requires a more profound, non-local change. This, in | particular, also makes it easier to understand the implications of the | first semantics. (Also, OCaml has made that same choice.) | | However, even with the first semantics, I still have one concern about | this proposal. The story about the interaction with existential types | is currently only partial and there is no discussion of the | interaction with GADTs. It might be reasonable to ask for a complete | specification of the interaction with these features before making a | final determination on this proposal. Nevertheless, this proposal is | quite elaborate and quite some work has gone into it. Hence, I think, | we owe it the authors of the proposal to at least make a preliminary | determination at this point. (In particular, if it is not going to fly | regardless of how GADTs are handled, we should say so now.) | | Cheers, | Manuel | | PS: It is worth noting that Swift solved the problem of deciding | between the first and second semantics by choosing a syntax that | avoids the ambiguity: | . It is difficult to adapt this syntax to Haskell. If it where | possible, I think, this would be the best solution. | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | committee From simonpj at microsoft.com Thu Nov 2 13:17:02 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 2 Nov 2017 13:17:02 +0000 Subject: [ghc-steering-committee] Underscores in numbers proposal In-Reply-To: References: Message-ID: I have not dug into the details, but the general direction of this proposal looks fine to me. Simion From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org] On Behalf Of Iavor Diatchki Sent: 01 November 2017 22:52 To: Christopher Allen Cc: ghc-steering-committee at haskell.org; Joachim Breitner Subject: Re: [ghc-steering-committee] Underscores in numbers proposal I am fine with this. Related to our recent discussion: we should probably require that this be protected by a language extension, like all other literal notations. Perhaps `UnderscoreLiterals`? -Iavor PS: technically, this is not backward compatible :-) Here is an example: instance Num b => Num (a -> b) where fromInteger = const . fromInteger test :: Integer test = 1_1 where _1 = 2 Currently this evaluates to 1, but with the extension it will evaluate to 11. I don't think that any real code would be affected by this, I just had a bit of fun writing it. On Wed, Nov 1, 2017 at 2:33 PM Christopher Allen > wrote: https://github.com/ghc-proposals/ghc-proposals/pull/76#issuecomment-339952996 This appears to have near universal approval. It's certainly a feature I've been grateful for when writing Rust code. I wasn't able to find a thread about this proposal in my email archives, so I apologize if this was redundant. Could this be moved to a decision soon? Thank you, Chris Allen _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From chak at justtesting.org Thu Nov 2 23:32:02 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Fri, 3 Nov 2017 10:32:02 +1100 Subject: [ghc-steering-committee] Proposal: Or patterns (#43) In-Reply-To: References: <90AB84AA-2917-49E6-B4A9-DF5E634A722F@justtesting.org> Message-ID: <4F993249-E6AB-4A0A-894C-C9AB3CC44361@justtesting.org> I agree with all that you are saying about the syntax, including that I really don’t see a good alternative. I didn’t know about the view patterns alternative. That is indeed an annoying potential overlap. Cheers, Manuel > Simon Marlow : > > I'm in favour of Or patterns with the non-backtracking semantics. While '|' is the natural syntax, it does have a couple of drawbacks: > > - it's the same as the guard syntax, and therefore potentially confusing (it might not seem confusing to us, because we're used to parsing Haskell in our heads, but to new users I'm sure this will be confusing) > - It interacts badly with this idea which I really hope we can make into a proper proposal one day: https://ghc.haskell.org/trac/ghc/wiki/ViewPatternsAlternative > > But '|' is also the syntax used for defining the constructor alternatives in a data type. So unless we intend to recommend GADT syntax exclusively in the future, it makes sense to use '|' for or-patterns. And I can't think of a good alternative. > > Cheers, > Simon > > > On 1 November 2017 at 23:57, Manuel M T Chakravarty > wrote: > Folks, > > I am sorry for taking a long time to get us going on this proposal. > > The ”Or pattern” proposal is about an extension to pattern matching: > > (formatted) https://github.com/osa1/ghc-proposals/blob/or_patterns/proposals/0000-or-patterns.rst > (PR thread) https://github.com/ghc-proposals/ghc-proposals/pull/43 > > Its basic idea is simple: allow multiple alternative patterns for each alternative during pattern matching. Unfortunately, the interaction with guards and some other languages features makes it significantly less straight forward than one might initially think. > > I propose to accept this proposal provided we can agree to use the ”first semantics” (aka single-match semantics) — see https://github.com/osa1/ghc-proposals/blob/or_patterns/proposals/0000-or-patterns.rst#interaction-with-guards > > My reason for insisting on the first semantics is that it is a simple extension of the existing pattern semantics in the Report, whereas the second semantics requires a more profound, non-local change. This, in particular, also makes it easier to understand the implications of the first semantics. (Also, OCaml has made that same choice.) > > However, even with the first semantics, I still have one concern about this proposal. The story about the interaction with existential types is currently only partial and there is no discussion of the interaction with GADTs. It might be reasonable to ask for a complete specification of the interaction with these features before making a final determination on this proposal. Nevertheless, this proposal is quite elaborate and quite some work has gone into it. Hence, I think, we owe it the authors of the proposal to at least make a preliminary determination at this point. (In particular, if it is not going to fly regardless of how GADTs are handled, we should say so now.) > > Cheers, > Manuel > > PS: It is worth noting that Swift solved the problem of deciding between the first and second semantics by choosing a syntax that avoids the ambiguity: >. It is difficult to adapt this syntax to Haskell. If it where possible, I think, this would be the best solution. > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chak at justtesting.org Thu Nov 2 23:40:29 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Fri, 3 Nov 2017 10:40:29 +1100 Subject: [ghc-steering-committee] Proposal: Or patterns (#43) In-Reply-To: References: <90AB84AA-2917-49E6-B4A9-DF5E634A722F@justtesting.org> Message-ID: <5921AD3F-5DE1-4E9E-A963-B292F41C186E@justtesting.org> You are right, the proposal must be complete before we can accept it. What I would like to suggest is the following: * If we all agree that *so far* this proposal is acceptable, we bounce it back to the authors saying that if they are able to fill in the gaps (especially, the treatment of GADTs) in a satisfactory manner, we will accept the proposal. * If we decide to reject the proposal, the authors can save themselves the effort of completing the specification. I know that this deviates from our usual procedure, but for a rather large piece of work that does show promise, I think, it is worthwhile to show some respect and appreciation for the effort spent. Cheers, Manuel > Simon Peyton Jones : > > In general I'm ok with this proposal. > > But I've just added a comment explaining some things that really need fleshing out. > > > > * The proposal should specify that in (p1 | p2) the patterns in p1 and p2 must bind the same set of variables, with the same types. Nothing else makes sense; but it is nowhere specified. > > * I'm concerned that the specification is incomplete. Certainly when it comes to GADTs there is some muttering about the prototype implementation, but no specification. > > * For GADTs it's clear to me that in (p1 | p2) the patterns p1 and p2 should bind the same set of existentials and the same set of type constraints (including class constraints), just as they must bind the same set of variables with the same types. Just write out the typing rules for patterns (which should be part of the proposal) and it'll all become clear! > > * I'm bothered by the stuff about view patterns, lazy patterns etc in the proposal. The point is: or-patterns has NO interaction with these patterns. We should just say that and stop! By having (quite long) sections about these features, but not (say) about tuple patterns, the implication is that there is something special to say. But there isn't. > > | My reason for insisting on the first semantics is that it is a simple > | extension of the existing pattern semantics in the Report, whereas the > | second semantics requires a more profound, non-local change. > > Definitely non-backtracking. The backtracking thing opens up a whole new can of worms. > > | quite elaborate and quite some work has gone into it. Hence, I think, > | we owe it the authors of the proposal to at least make a preliminary > | determination at this point. (In particular, if it is not going to fly > | regardless of how GADTs are handled, we should say so now.) > > I agree with that... but I'd be reluctant to actually accept it into GHC unless it was fully compositional, including GADTs. So it'd be a conditional acceptance, subject to satisfactory resolution of the GADT question. I'm not sure how the implementation works out... let's see; probably fine. > > > Simon > > | -----Original Message----- > | From: ghc-steering-committee [mailto:ghc-steering-committee- > | bounces at haskell.org] On Behalf Of Manuel M T Chakravarty > | Sent: 01 November 2017 23:58 > | To: ghc-steering-committee at haskell.org > | Subject: [ghc-steering-committee] Proposal: Or patterns (#43) > | > | Folks, > | > | I am sorry for taking a long time to get us going on this proposal. > | > | The ”Or pattern” proposal is about an extension to pattern matching: > | > | (formatted) > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu > | b.com%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000- > | or- > | patterns.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad54503 > | 0e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177 > | 4805951860&sdata=ivKxIr7%2FprF1GhUBq%2BZRxJjmKqfPq%2BNOXmbw9JPJuQ8%3D& > | reserved=0 > | (PR thread) > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu > | b.com%2Fghc-proposals%2Fghc- > | proposals%2Fpull%2F43&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be > | 72ad545030e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7 > | C636451774805951860&sdata=x0Xn%2BOS6mHZBWYolcaJfa5JCkbHa1pl552fNI1Swmh > | w%3D&reserved=0 > | > | Its basic idea is simple: allow multiple alternative patterns for each > | alternative during pattern matching. Unfortunately, the interaction > | with guards and some other languages features makes it significantly > | less straight forward than one might initially think. > | > | I propose to accept this proposal provided we can agree to use the > | ”first semantics” (aka single-match semantics) — see > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu > | b.com%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000- > | or-patterns.rst%23interaction-with- > | guards&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3c08 > | d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480595 > | 1860&sdata=Z5JJApLfReiCl0dKD2R%2Fvbs3pTZt84iEXDRhdbeVICA%3D&reserved=0 > | > | My reason for insisting on the first semantics is that it is a simple > | extension of the existing pattern semantics in the Report, whereas the > | second semantics requires a more profound, non-local change. This, in > | particular, also makes it easier to understand the implications of the > | first semantics. (Also, OCaml has made that same choice.) > | > | However, even with the first semantics, I still have one concern about > | this proposal. The story about the interaction with existential types > | is currently only partial and there is no discussion of the > | interaction with GADTs. It might be reasonable to ask for a complete > | specification of the interaction with these features before making a > | final determination on this proposal. Nevertheless, this proposal is > | quite elaborate and quite some work has gone into it. Hence, I think, > | we owe it the authors of the proposal to at least make a preliminary > | determination at this point. (In particular, if it is not going to fly > | regardless of how GADTs are handled, we should say so now.) > | > | Cheers, > | Manuel > | > | PS: It is worth noting that Swift solved the problem of deciding > | between the first and second semantics by choosing a syntax that > | avoids the ambiguity: > | | loper.apple.com%2Flibrary%2Fcontent%2Fdocumentation%2FSwift%2FConceptu > | al%2FSwift_Programming_Language%2FStatements.html%23%2F%2Fapple_ref%2F > | swift%2Fgrammar%2Fswitch- > | statement&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3 > | c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480 > | 5951860&sdata=ax1RcoY80ERbid5inoe%2BCRYg%2FC4t0hVL5oGBasVTfhM%3D&reser > | ved=0>. It is difficult to adapt this syntax to Haskell. If it where > | possible, I think, this would be the best solution. > | _______________________________________________ > | ghc-steering-committee mailing list > | ghc-steering-committee at haskell.org > | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > | committee From simonpj at microsoft.com Fri Nov 3 08:40:24 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 3 Nov 2017 08:40:24 +0000 Subject: [ghc-steering-committee] Proposal: Or patterns (#43) In-Reply-To: <5921AD3F-5DE1-4E9E-A963-B292F41C186E@justtesting.org> References: <90AB84AA-2917-49E6-B4A9-DF5E634A722F@justtesting.org> <5921AD3F-5DE1-4E9E-A963-B292F41C186E@justtesting.org> Message-ID: I'm ok with what you propose S | -----Original Message----- | From: Manuel M T Chakravarty [mailto:chak at justtesting.org] | Sent: 02 November 2017 23:40 | To: Simon Peyton Jones | Cc: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] Proposal: Or patterns (#43) | | You are right, the proposal must be complete before we can accept it. | What I would like to suggest is the following: | | * If we all agree that *so far* this proposal is acceptable, we bounce | it back to the authors saying that if they are able to fill in the | gaps (especially, the treatment of GADTs) in a satisfactory manner, we | will accept the proposal. | | * If we decide to reject the proposal, the authors can save themselves | the effort of completing the specification. | | I know that this deviates from our usual procedure, but for a rather | large piece of work that does show promise, I think, it is worthwhile | to show some respect and appreciation for the effort spent. | | Cheers, | Manuel | | > Simon Peyton Jones : | > | > In general I'm ok with this proposal. | > | > But I've just added a comment explaining some things that really | need fleshing out. | > | > | > | > * The proposal should specify that in (p1 | p2) the patterns in p1 | and p2 must bind the same set of variables, with the same types. | Nothing else makes sense; but it is nowhere specified. | > | > * I'm concerned that the specification is incomplete. Certainly when | it comes to GADTs there is some muttering about the prototype | implementation, but no specification. | > | > * For GADTs it's clear to me that in (p1 | p2) the patterns p1 and | p2 should bind the same set of existentials and the same set of type | constraints (including class constraints), just as they must bind the | same set of variables with the same types. Just write out the typing | rules for patterns (which should be part of the proposal) and it'll | all become clear! | > | > * I'm bothered by the stuff about view patterns, lazy patterns etc | in the proposal. The point is: or-patterns has NO interaction with | these patterns. We should just say that and stop! By having (quite | long) sections about these features, but not (say) about tuple | patterns, the implication is that there is something special to say. | But there isn't. | > | > | My reason for insisting on the first semantics is that it is a | > | simple extension of the existing pattern semantics in the Report, | > | whereas the second semantics requires a more profound, non-local | change. | > | > Definitely non-backtracking. The backtracking thing opens up a | whole new can of worms. | > | > | quite elaborate and quite some work has gone into it. Hence, I | > | think, we owe it the authors of the proposal to at least make a | > | preliminary determination at this point. (In particular, if it is | > | not going to fly regardless of how GADTs are handled, we should | say | > | so now.) | > | > I agree with that... but I'd be reluctant to actually accept it into | GHC unless it was fully compositional, including GADTs. So it'd be a | conditional acceptance, subject to satisfactory resolution of the GADT | question. I'm not sure how the implementation works out... let's see; | probably fine. | > | > | > Simon | > | > | -----Original Message----- | > | From: ghc-steering-committee [mailto:ghc-steering-committee- | > | bounces at haskell.org] On Behalf Of Manuel M T Chakravarty | > | Sent: 01 November 2017 23:58 | > | To: ghc-steering-committee at haskell.org | > | Subject: [ghc-steering-committee] Proposal: Or patterns (#43) | > | | > | Folks, | > | | > | I am sorry for taking a long time to get us going on this | proposal. | > | | > | The ”Or pattern” proposal is about an extension to pattern | matching: | > | | > | (formatted) | > | | > | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit | > | hu | > | | > | b.com%2Fosa1%2Fghc- | proposals%2Fblob%2For_patterns%2Fproposals%2F0000 | > | - | > | or- | > | | > | | patterns.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545 | > | 03 | > | | > | | 0e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636451 | > | 77 | > | | 4805951860&sdata=ivKxIr7%2FprF1GhUBq%2BZRxJjmKqfPq%2BNOXmbw9JPJuQ8%3 | > | D& | > | reserved=0 | > | (PR thread) | > | | > | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit | > | hu | > | b.com%2Fghc-proposals%2Fghc- | > | | > | | proposals%2Fpull%2F43&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6 | > | be | > | | > | | 72ad545030e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0 | > | %7 | > | | C636451774805951860&sdata=x0Xn%2BOS6mHZBWYolcaJfa5JCkbHa1pl552fNI1Sw | > | mh | > | w%3D&reserved=0 | > | | > | Its basic idea is simple: allow multiple alternative patterns for | > | each alternative during pattern matching. Unfortunately, the | > | interaction with guards and some other languages features makes | it | > | significantly less straight forward than one might initially | think. | > | | > | I propose to accept this proposal provided we can agree to use | the | > | ”first semantics” (aka single-match semantics) — see | > | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit | > | hu | > | | > | b.com%2Fosa1%2Fghc- | proposals%2Fblob%2For_patterns%2Fproposals%2F0000 | > | - | > | or-patterns.rst%23interaction-with- | > | | > | | guards&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3c | > | 08 | > | | > | | d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636451774805 | > | 95 | > | | > | | 1860&sdata=Z5JJApLfReiCl0dKD2R%2Fvbs3pTZt84iEXDRhdbeVICA%3D&reserved | > | =0 | > | | > | My reason for insisting on the first semantics is that it is a | > | simple extension of the existing pattern semantics in the Report, | > | whereas the second semantics requires a more profound, non-local | > | change. This, in particular, also makes it easier to understand | the | > | implications of the first semantics. (Also, OCaml has made that | > | same choice.) | > | | > | However, even with the first semantics, I still have one concern | > | about this proposal. The story about the interaction with | > | existential types is currently only partial and there is no | > | discussion of the interaction with GADTs. It might be reasonable | to | > | ask for a complete specification of the interaction with these | > | features before making a final determination on this proposal. | > | Nevertheless, this proposal is quite elaborate and quite some | work | > | has gone into it. Hence, I think, we owe it the authors of the | > | proposal to at least make a preliminary determination at this | > | point. (In particular, if it is not going to fly regardless of | how | > | GADTs are handled, we should say so now.) | > | | > | Cheers, | > | Manuel | > | | > | PS: It is worth noting that Swift solved the problem of deciding | > | between the first and second semantics by choosing a syntax that | > | avoids the ambiguity: | > | | > | | | ve | > | | loper.apple.com%2Flibrary%2Fcontent%2Fdocumentation%2FSwift%2FConcep | > | tu | > | | al%2FSwift_Programming_Language%2FStatements.html%23%2F%2Fapple_ref% | > | 2F | > | swift%2Fgrammar%2Fswitch- | > | | > | | statement&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030 | > | e3 | > | | > | | c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636451774 | > | 80 | > | | 5951860&sdata=ax1RcoY80ERbid5inoe%2BCRYg%2FC4t0hVL5oGBasVTfhM%3D&res | > | er ved=0>. It is difficult to adapt this syntax to Haskell. If it | > | where possible, I think, this would be the best solution. | > | _______________________________________________ | > | ghc-steering-committee mailing list | > | ghc-steering-committee at haskell.org | > | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | > | committee From mail at joachim-breitner.de Fri Nov 3 13:19:17 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 03 Nov 2017 09:19:17 -0400 Subject: [ghc-steering-committee] Proposal: Or patterns (#43) In-Reply-To: <5921AD3F-5DE1-4E9E-A963-B292F41C186E@justtesting.org> References: <90AB84AA-2917-49E6-B4A9-DF5E634A722F@justtesting.org> <5921AD3F-5DE1-4E9E-A963-B292F41C186E@justtesting.org> Message-ID: <1509715157.3052.0.camel@joachim-breitner.de> Hi, from a procedural point of view, that’s fine: We can certainly ask for improvements to a proposal, and there is even a “Needs revision” label for it. Joachim Am Freitag, den 03.11.2017, 10:40 +1100 schrieb Manuel M T Chakravarty: > You are right, the proposal must be complete before we can accept it. What I would like to suggest is the following: > > * If we all agree that *so far* this proposal is acceptable, we bounce it back to the authors saying that if they are able to fill in the gaps (especially, the treatment of GADTs) in a satisfactory manner, we will accept the proposal. > > * If we decide to reject the proposal, the authors can save themselves the effort of completing the specification. > > I know that this deviates from our usual procedure, but for a rather large piece of work that does show promise, I think, it is worthwhile to show some respect and appreciation for the effort spent. > > Cheers, > Manuel > > > Simon Peyton Jones : > > > > In general I'm ok with this proposal. > > > > But I've just added a comment explaining some things that really need fleshing out. > > > > > > > > * The proposal should specify that in (p1 | p2) the patterns in p1 and p2 must bind the same set of variables, with the same types. Nothing else makes sense; but it is nowhere specified. > > > > * I'm concerned that the specification is incomplete. Certainly when it comes to GADTs there is some muttering about the prototype implementation, but no specification. > > > > * For GADTs it's clear to me that in (p1 | p2) the patterns p1 and p2 should bind the same set of existentials and the same set of type constraints (including class constraints), just as they must bind the same set of variables with the same types. Just write out the typing rules for patterns (which should be part of the proposal) and it'll all become clear! > > > > * I'm bothered by the stuff about view patterns, lazy patterns etc in the proposal. The point is: or-patterns has NO interaction with these patterns. We should just say that and stop! By having (quite long) sections about these features, but not (say) about tuple patterns, the implication is that there is something special to say. But there isn't. > > > > > My reason for insisting on the first semantics is that it is a simple > > > extension of the existing pattern semantics in the Report, whereas the > > > second semantics requires a more profound, non-local change. > > > > Definitely non-backtracking. The backtracking thing opens up a whole new can of worms. > > > > > quite elaborate and quite some work has gone into it. Hence, I think, > > > we owe it the authors of the proposal to at least make a preliminary > > > determination at this point. (In particular, if it is not going to fly > > > regardless of how GADTs are handled, we should say so now.) > > > > I agree with that... but I'd be reluctant to actually accept it into GHC unless it was fully compositional, including GADTs. So it'd be a conditional acceptance, subject to satisfactory resolution of the GADT question. I'm not sure how the implementation works out... let's see; probably fine. > > > > > > Simon > > > > > -----Original Message----- > > > From: ghc-steering-committee [mailto:ghc-steering-committee- > > > bounces at haskell.org] On Behalf Of Manuel M T Chakravarty > > > Sent: 01 November 2017 23:58 > > > To: ghc-steering-committee at haskell.org > > > Subject: [ghc-steering-committee] Proposal: Or patterns (#43) > > > > > > Folks, > > > > > > I am sorry for taking a long time to get us going on this proposal. > > > > > > The ”Or pattern” proposal is about an extension to pattern matching: > > > > > > (formatted) > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu > > > b.com%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000- > > > or- > > > patterns.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad54503 > > > 0e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177 > > > 4805951860&sdata=ivKxIr7%2FprF1GhUBq%2BZRxJjmKqfPq%2BNOXmbw9JPJuQ8%3D& > > > reserved=0 > > > (PR thread) > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu > > > b.com%2Fghc-proposals%2Fghc- > > > proposals%2Fpull%2F43&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be > > > 72ad545030e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7 > > > C636451774805951860&sdata=x0Xn%2BOS6mHZBWYolcaJfa5JCkbHa1pl552fNI1Swmh > > > w%3D&reserved=0 > > > > > > Its basic idea is simple: allow multiple alternative patterns for each > > > alternative during pattern matching. Unfortunately, the interaction > > > with guards and some other languages features makes it significantly > > > less straight forward than one might initially think. > > > > > > I propose to accept this proposal provided we can agree to use the > > > ”first semantics” (aka single-match semantics) — see > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu > > > b.com%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000- > > > or-patterns.rst%23interaction-with- > > > guards&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3c08 > > > d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480595 > > > 1860&sdata=Z5JJApLfReiCl0dKD2R%2Fvbs3pTZt84iEXDRhdbeVICA%3D&reserved=0 > > > > > > My reason for insisting on the first semantics is that it is a simple > > > extension of the existing pattern semantics in the Report, whereas the > > > second semantics requires a more profound, non-local change. This, in > > > particular, also makes it easier to understand the implications of the > > > first semantics. (Also, OCaml has made that same choice.) > > > > > > However, even with the first semantics, I still have one concern about > > > this proposal. The story about the interaction with existential types > > > is currently only partial and there is no discussion of the > > > interaction with GADTs. It might be reasonable to ask for a complete > > > specification of the interaction with these features before making a > > > final determination on this proposal. Nevertheless, this proposal is > > > quite elaborate and quite some work has gone into it. Hence, I think, > > > we owe it the authors of the proposal to at least make a preliminary > > > determination at this point. (In particular, if it is not going to fly > > > regardless of how GADTs are handled, we should say so now.) > > > > > > Cheers, > > > Manuel > > > > > > PS: It is worth noting that Swift solved the problem of deciding > > > between the first and second semantics by choosing a syntax that > > > avoids the ambiguity: > > > > > loper.apple.com%2Flibrary%2Fcontent%2Fdocumentation%2FSwift%2FConceptu > > > al%2FSwift_Programming_Language%2FStatements.html%23%2F%2Fapple_ref%2F > > > swift%2Fgrammar%2Fswitch- > > > statement&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3 > > > c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480 > > > 5951860&sdata=ax1RcoY80ERbid5inoe%2BCRYg%2FC4t0hVL5oGBasVTfhM%3D&reser > > > ved=0>. It is difficult to adapt this syntax to Haskell. If it where > > > possible, I think, this would be the best solution. > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > ghc-steering-committee at haskell.org > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > > > committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From iavor.diatchki at gmail.com Tue Nov 7 18:03:10 2017 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 07 Nov 2017 18:03:10 +0000 Subject: [ghc-steering-committee] Proposal: Or patterns (#43) In-Reply-To: <1509715157.3052.0.camel@joachim-breitner.de> References: <90AB84AA-2917-49E6-B4A9-DF5E634A722F@justtesting.org> <5921AD3F-5DE1-4E9E-A963-B292F41C186E@justtesting.org> <1509715157.3052.0.camel@joachim-breitner.de> Message-ID: Hello, I think that in principle the or-pattern patter idea is fine, but I am a bit wary of accepting it as is for two reasons: 1. The syntax conflict with the view pattern proposal is unfortunate---I really like this idea, and I wrote up basically the exact same thing in my dissertation a long time ago, where I called it "guarded patterns". Very handy I think. 2. The story about pattern contexts seems unclear (i.e., extistentials and GADTs). To work around the first one, how about we use double bar (i.e., ||) to separate the Or pattern? The single bar does feel more natural though... For the second one, I can see two options: A) do not allow or patterns if any of the patterns contain constraint B) come up with a mechanism to compute the intersection of constraints. For this I can see a few options: B.1) Fancy intersection, where the different branches of the or-patterns may define additional evidence bindings (be it dictionaries or coercions). B.2) Simple intersection, where we only pick constraints from the contexts that match exactly. -Iavor On Fri, Nov 3, 2017 at 6:19 AM Joachim Breitner wrote: > Hi, > > from a procedural point of view, that’s fine: We can certainly ask for > improvements to a proposal, and there is even a “Needs revision” label > for it. > > Joachim > > Am Freitag, den 03.11.2017, 10:40 +1100 schrieb Manuel M T Chakravarty: > > You are right, the proposal must be complete before we can accept it. > What I would like to suggest is the following: > > > > * If we all agree that *so far* this proposal is acceptable, we bounce > it back to the authors saying that if they are able to fill in the gaps > (especially, the treatment of GADTs) in a satisfactory manner, we will > accept the proposal. > > > > * If we decide to reject the proposal, the authors can save themselves > the effort of completing the specification. > > > > I know that this deviates from our usual procedure, but for a rather > large piece of work that does show promise, I think, it is worthwhile to > show some respect and appreciation for the effort spent. > > > > Cheers, > > Manuel > > > > > Simon Peyton Jones : > > > > > > In general I'm ok with this proposal. > > > > > > But I've just added a comment explaining some things that really need > fleshing out. > > > > > > > > > > > > * The proposal should specify that in (p1 | p2) the patterns in p1 and > p2 must bind the same set of variables, with the same types. Nothing else > makes sense; but it is nowhere specified. > > > > > > * I'm concerned that the specification is incomplete. Certainly when > it comes to GADTs there is some muttering about the prototype > implementation, but no specification. > > > > > > * For GADTs it's clear to me that in (p1 | p2) the patterns p1 and p2 > should bind the same set of existentials and the same set of type > constraints (including class constraints), just as they must bind the same > set of variables with the same types. Just write out the typing rules for > patterns (which should be part of the proposal) and it'll all become clear! > > > > > > * I'm bothered by the stuff about view patterns, lazy patterns etc in > the proposal. The point is: or-patterns has NO interaction with these > patterns. We should just say that and stop! By having (quite long) sections > about these features, but not (say) about tuple patterns, the implication > is that there is something special to say. But there isn't. > > > > > > > My reason for insisting on the first semantics is that it is a > simple > > > > extension of the existing pattern semantics in the Report, whereas > the > > > > second semantics requires a more profound, non-local change. > > > > > > Definitely non-backtracking. The backtracking thing opens up a whole > new can of worms. > > > > > > > quite elaborate and quite some work has gone into it. Hence, I > think, > > > > we owe it the authors of the proposal to at least make a preliminary > > > > determination at this point. (In particular, if it is not going to > fly > > > > regardless of how GADTs are handled, we should say so now.) > > > > > > I agree with that... but I'd be reluctant to actually accept it into > GHC unless it was fully compositional, including GADTs. So it'd be a > conditional acceptance, subject to satisfactory resolution of the GADT > question. I'm not sure how the implementation works out... let's see; > probably fine. > > > > > > > > > Simon > > > > > > > -----Original Message----- > > > > From: ghc-steering-committee [mailto:ghc-steering-committee- > > > > bounces at haskell.org] On Behalf Of Manuel M T Chakravarty > > > > Sent: 01 November 2017 23:58 > > > > To: ghc-steering-committee at haskell.org > > > > Subject: [ghc-steering-committee] Proposal: Or patterns (#43) > > > > > > > > Folks, > > > > > > > > I am sorry for taking a long time to get us going on this proposal. > > > > > > > > The ”Or pattern” proposal is about an extension to pattern matching: > > > > > > > > (formatted) > > > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu > > > > b.com > %2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000- > > > > or- > > > > patterns.rst&data=02%7C01%7Csimonpj%40microsoft.com > %7Cc41b6be72ad54503 > > > > > 0e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177 > > > > 4805951860 <(480)%20595-1860> > &sdata=ivKxIr7%2FprF1GhUBq%2BZRxJjmKqfPq%2BNOXmbw9JPJuQ8%3D& > > > > reserved=0 > > > > (PR thread) > > > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu > > > > b.com%2Fghc-proposals%2Fghc- > > > > proposals%2Fpull%2F43&data=02%7C01%7Csimonpj%40microsoft.com > %7Cc41b6be > > > > > 72ad545030e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7 > > > > > C636451774805951860&sdata=x0Xn%2BOS6mHZBWYolcaJfa5JCkbHa1pl552fNI1Swmh > > > > w%3D&reserved=0 > > > > > > > > Its basic idea is simple: allow multiple alternative patterns for > each > > > > alternative during pattern matching. Unfortunately, the interaction > > > > with guards and some other languages features makes it significantly > > > > less straight forward than one might initially think. > > > > > > > > I propose to accept this proposal provided we can agree to use the > > > > ”first semantics” (aka single-match semantics) — see > > > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu > > > > b.com > %2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000- > > > > or-patterns.rst%23interaction-with- > > > > guards&data=02%7C01%7Csimonpj%40microsoft.com > %7Cc41b6be72ad545030e3c08 > > > > > d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480595 > > > > > 1860&sdata=Z5JJApLfReiCl0dKD2R%2Fvbs3pTZt84iEXDRhdbeVICA%3D&reserved=0 > > > > > > > > My reason for insisting on the first semantics is that it is a > simple > > > > extension of the existing pattern semantics in the Report, whereas > the > > > > second semantics requires a more profound, non-local change. This, > in > > > > particular, also makes it easier to understand the implications of > the > > > > first semantics. (Also, OCaml has made that same choice.) > > > > > > > > However, even with the first semantics, I still have one concern > about > > > > this proposal. The story about the interaction with existential > types > > > > is currently only partial and there is no discussion of the > > > > interaction with GADTs. It might be reasonable to ask for a complete > > > > specification of the interaction with these features before making a > > > > final determination on this proposal. Nevertheless, this proposal is > > > > quite elaborate and quite some work has gone into it. Hence, I > think, > > > > we owe it the authors of the proposal to at least make a preliminary > > > > determination at this point. (In particular, if it is not going to > fly > > > > regardless of how GADTs are handled, we should say so now.) > > > > > > > > Cheers, > > > > Manuel > > > > > > > > PS: It is worth noting that Swift solved the problem of deciding > > > > between the first and second semantics by choosing a syntax that > > > > avoids the ambiguity: > > > > < > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve > > > > loper.apple.com > %2Flibrary%2Fcontent%2Fdocumentation%2FSwift%2FConceptu > > > > > al%2FSwift_Programming_Language%2FStatements.html%23%2F%2Fapple_ref%2F > > > > swift%2Fgrammar%2Fswitch- > > > > statement&data=02%7C01%7Csimonpj%40microsoft.com > %7Cc41b6be72ad545030e3 > > > > > c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480 > > > > > 5951860&sdata=ax1RcoY80ERbid5inoe%2BCRYg%2FC4t0hVL5oGBasVTfhM%3D&reser > > > > ved=0>. It is difficult to adapt this syntax to Haskell. If it where > > > > possible, I think, this would be the best solution. > > > > _______________________________________________ > > > > ghc-steering-committee mailing list > > > > ghc-steering-committee at haskell.org > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > > > > committee > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Tue Nov 7 18:11:57 2017 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 07 Nov 2017 18:11:57 +0000 Subject: [ghc-steering-committee] Underscores in literals Message-ID: Hello, This e-mail is about pull request #76, to allow underscores in numeric literals: https://github.com/takenobu-hs/ghc-proposals/blob/numeric-underscores/proposals/0000-numeric-underscores.rst In short, this is a very simply feature, which modifies the notation for numeric literals to allow writing underscores (_) in the middle of literals. The underscores are only to increase readability, and have no effect on the meaning of the program. So, for example, I could write things like: 10_000_072 or 0xFFFF_FA10. Many other languages have a similar feature (especially hardware specification languages) and I see no downsides to it, so I think we should accept it. Please respond to this e-mail if you have objections. Cheers, -Iavor -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Nov 7 18:56:27 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 7 Nov 2017 18:56:27 +0000 Subject: [ghc-steering-committee] Underscores in literals In-Reply-To: References: Message-ID: I’m ok with this, although I have not thought deeply about the details. Simon From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org] On Behalf Of Iavor Diatchki Sent: 07 November 2017 18:12 To: ghc-steering-committee at haskell.org Subject: [ghc-steering-committee] Underscores in literals Hello, This e-mail is about pull request #76, to allow underscores in numeric literals: https://github.com/takenobu-hs/ghc-proposals/blob/numeric-underscores/proposals/0000-numeric-underscores.rst In short, this is a very simply feature, which modifies the notation for numeric literals to allow writing underscores (_) in the middle of literals. The underscores are only to increase readability, and have no effect on the meaning of the program. So, for example, I could write things like: 10_000_072 or 0xFFFF_FA10. Many other languages have a similar feature (especially hardware specification languages) and I see no downsides to it, so I think we should accept it. Please respond to this e-mail if you have objections. Cheers, -Iavor -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Nov 7 19:04:53 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 7 Nov 2017 19:04:53 +0000 Subject: [ghc-steering-committee] Proposal: Or patterns (#43) In-Reply-To: References: <90AB84AA-2917-49E6-B4A9-DF5E634A722F@justtesting.org> <5921AD3F-5DE1-4E9E-A963-B292F41C186E@justtesting.org> <1509715157.3052.0.camel@joachim-breitner.de> Message-ID: 1. The syntax conflict with the view pattern proposal is unfortunate---I really like this idea, and I wrote up basically the exact same thing in my dissertation a long time ago, where I called it "guarded patterns". Very handy I think. Yes… I too wondered about ||, although then we’d run into trouble with definitions of the function (||). It seems hard to not-accept a proposal because it conflicts with another un-submitted one. But that’s just a question of specifying which wins in the ambiguous case p1 || p2 = e I like the fact that || is a bit noisier; we are using | for guards already. We should only allow it infix. Would someone like to submit the view-pattern proposal? For the second one, I can see two options: A) do not allow or patterns if any of the patterns contain constraint B) come up with a mechanism to compute the intersection of constraints I prefer (C): require exactly the same constraints bound in both patterns. Same as we require exactly the same variables bound. We could loosen up later. From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org] On Behalf Of Iavor Diatchki Sent: 07 November 2017 18:03 To: Joachim Breitner Cc: ghc-steering-committee at haskell.org Subject: Re: [ghc-steering-committee] Proposal: Or patterns (#43) Hello, I think that in principle the or-pattern patter idea is fine, but I am a bit wary of accepting it as is for two reasons: 1. The syntax conflict with the view pattern proposal is unfortunate---I really like this idea, and I wrote up basically the exact same thing in my dissertation a long time ago, where I called it "guarded patterns". Very handy I think. 2. The story about pattern contexts seems unclear (i.e., extistentials and GADTs). To work around the first one, how about we use double bar (i.e., ||) to separate the Or pattern? The single bar does feel more natural though... For the second one, I can see two options: A) do not allow or patterns if any of the patterns contain constraint B) come up with a mechanism to compute the intersection of constraints. For this I can see a few options: B.1) Fancy intersection, where the different branches of the or-patterns may define additional evidence bindings (be it dictionaries or coercions). B.2) Simple intersection, where we only pick constraints from the contexts that match exactly. -Iavor On Fri, Nov 3, 2017 at 6:19 AM Joachim Breitner > wrote: Hi, from a procedural point of view, that’s fine: We can certainly ask for improvements to a proposal, and there is even a “Needs revision” label for it. Joachim Am Freitag, den 03.11.2017, 10:40 +1100 schrieb Manuel M T Chakravarty: > You are right, the proposal must be complete before we can accept it. What I would like to suggest is the following: > > * If we all agree that *so far* this proposal is acceptable, we bounce it back to the authors saying that if they are able to fill in the gaps (especially, the treatment of GADTs) in a satisfactory manner, we will accept the proposal. > > * If we decide to reject the proposal, the authors can save themselves the effort of completing the specification. > > I know that this deviates from our usual procedure, but for a rather large piece of work that does show promise, I think, it is worthwhile to show some respect and appreciation for the effort spent. > > Cheers, > Manuel > > > Simon Peyton Jones >: > > > > In general I'm ok with this proposal. > > > > But I've just added a comment explaining some things that really need fleshing out. > > > > > > > > * The proposal should specify that in (p1 | p2) the patterns in p1 and p2 must bind the same set of variables, with the same types. Nothing else makes sense; but it is nowhere specified. > > > > * I'm concerned that the specification is incomplete. Certainly when it comes to GADTs there is some muttering about the prototype implementation, but no specification. > > > > * For GADTs it's clear to me that in (p1 | p2) the patterns p1 and p2 should bind the same set of existentials and the same set of type constraints (including class constraints), just as they must bind the same set of variables with the same types. Just write out the typing rules for patterns (which should be part of the proposal) and it'll all become clear! > > > > * I'm bothered by the stuff about view patterns, lazy patterns etc in the proposal. The point is: or-patterns has NO interaction with these patterns. We should just say that and stop! By having (quite long) sections about these features, but not (say) about tuple patterns, the implication is that there is something special to say. But there isn't. > > > > > My reason for insisting on the first semantics is that it is a simple > > > extension of the existing pattern semantics in the Report, whereas the > > > second semantics requires a more profound, non-local change. > > > > Definitely non-backtracking. The backtracking thing opens up a whole new can of worms. > > > > > quite elaborate and quite some work has gone into it. Hence, I think, > > > we owe it the authors of the proposal to at least make a preliminary > > > determination at this point. (In particular, if it is not going to fly > > > regardless of how GADTs are handled, we should say so now.) > > > > I agree with that... but I'd be reluctant to actually accept it into GHC unless it was fully compositional, including GADTs. So it'd be a conditional acceptance, subject to satisfactory resolution of the GADT question. I'm not sure how the implementation works out... let's see; probably fine. > > > > > > Simon > > > > > -----Original Message----- > > > From: ghc-steering-committee [mailto:ghc-steering-committee- > > > bounces at haskell.org] On Behalf Of Manuel M T Chakravarty > > > Sent: 01 November 2017 23:58 > > > To: ghc-steering-committee at haskell.org > > > Subject: [ghc-steering-committee] Proposal: Or patterns (#43) > > > > > > Folks, > > > > > > I am sorry for taking a long time to get us going on this proposal. > > > > > > The ”Or pattern” proposal is about an extension to pattern matching: > > > > > > (formatted) > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu > > > b.com%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000- > > > or- > > > patterns.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad54503 > > > 0e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177 > > > 4805951860&sdata=ivKxIr7%2FprF1GhUBq%2BZRxJjmKqfPq%2BNOXmbw9JPJuQ8%3D& > > > reserved=0 > > > (PR thread) > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu > > > b.com%2Fghc-proposals%2Fghc- > > > proposals%2Fpull%2F43&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be > > > 72ad545030e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7 > > > C636451774805951860&sdata=x0Xn%2BOS6mHZBWYolcaJfa5JCkbHa1pl552fNI1Swmh > > > w%3D&reserved=0 > > > > > > Its basic idea is simple: allow multiple alternative patterns for each > > > alternative during pattern matching. Unfortunately, the interaction > > > with guards and some other languages features makes it significantly > > > less straight forward than one might initially think. > > > > > > I propose to accept this proposal provided we can agree to use the > > > ”first semantics” (aka single-match semantics) — see > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu > > > b.com%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000- > > > or-patterns.rst%23interaction-with- > > > guards&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3c08 > > > d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480595 > > > 1860&sdata=Z5JJApLfReiCl0dKD2R%2Fvbs3pTZt84iEXDRhdbeVICA%3D&reserved=0 > > > > > > My reason for insisting on the first semantics is that it is a simple > > > extension of the existing pattern semantics in the Report, whereas the > > > second semantics requires a more profound, non-local change. This, in > > > particular, also makes it easier to understand the implications of the > > > first semantics. (Also, OCaml has made that same choice.) > > > > > > However, even with the first semantics, I still have one concern about > > > this proposal. The story about the interaction with existential types > > > is currently only partial and there is no discussion of the > > > interaction with GADTs. It might be reasonable to ask for a complete > > > specification of the interaction with these features before making a > > > final determination on this proposal. Nevertheless, this proposal is > > > quite elaborate and quite some work has gone into it. Hence, I think, > > > we owe it the authors of the proposal to at least make a preliminary > > > determination at this point. (In particular, if it is not going to fly > > > regardless of how GADTs are handled, we should say so now.) > > > > > > Cheers, > > > Manuel > > > > > > PS: It is worth noting that Swift solved the problem of deciding > > > between the first and second semantics by choosing a syntax that > > > avoids the ambiguity: > > > > > loper.apple.com%2Flibrary%2Fcontent%2Fdocumentation%2FSwift%2FConceptu > > > al%2FSwift_Programming_Language%2FStatements.html%23%2F%2Fapple_ref%2F > > > swift%2Fgrammar%2Fswitch- > > > statement&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3 > > > c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480 > > > 5951860&sdata=ax1RcoY80ERbid5inoe%2BCRYg%2FC4t0hVL5oGBasVTfhM%3D&reser > > > ved=0>. It is difficult to adapt this syntax to Haskell. If it where > > > possible, I think, this would be the best solution. > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > ghc-steering-committee at haskell.org > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > > > committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri Nov 10 19:05:02 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 10 Nov 2017 14:05:02 -0500 Subject: [ghc-steering-committee] Status Message-ID: <1510340702.13501.8.camel@joachim-breitner.de> Dear Commmittteee, Since the last status update, we * accepted the following proposals: - Type Fixity * sent the following proposals back for further refinement - NOUNPACK on function arguments * rejected the following proposals: - /none/ * were asked to review these proposals: - underscore in numeric literals * had a discussion about language extensions stability, which has been moved to a proposal of its own at https://github.com/ghc-proposals/ghc-proposals/pull/85 and has since quieted down. It is unclear if this will happen. On our table at the moment are: Lazy unboxed tuples https://github.com/ghc-proposals/ghc-proposals/pull/35 Shepherd: Ryan Newton Status: Still waiting for Ryan to make a recommendation. Mutable constructor fields https://github.com/ghc-proposals/ghc-proposals/pull/8 Shepherd: Ryan Newton Status: Still waiting for Ryan to make a recommendation. Or Patterns https://github.com/ghc-proposals/ghc-proposals/pull/43 Shepherd: Manuel Chakravarty Status: Manuel suggests acceptance, committee deliberation ongoing Underscores in numeric literals https://github.com/ghc-proposals/ghc-proposals/pull/76 Shepherd: Iavor Diachki Status: Iavor suggests acceptance, I sense silent agreement in the committee Besides these, there are some proposals actively under discussion. You can always check them out at https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+no%3Alabel Greetings, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Fri Nov 10 19:41:35 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 10 Nov 2017 14:41:35 -0500 Subject: [ghc-steering-committee] Please review: visible dependent quantification, Shepherd: Roman Leshchinskiy Message-ID: <1510342895.13501.10.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: Visible dependent quantification (TL;DR: forall k -> k -> *) https://github.com/ghc-proposals/ghc-proposals/pull/81 was brought before the committee, by our own Richard Eisenberg. I propose Roman Leshchinskiy as the Shepherd. Roman, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Fri Nov 10 20:42:41 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 10 Nov 2017 15:42:41 -0500 Subject: [ghc-steering-committee] Please review: Deprecate STM invariant, Shepherd: Manuel M T Chakravarty Message-ID: <1510346561.16051.1.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: Deprecate STM invariant mechanism https://github.com/ghc-proposals/ghc-proposals/pull/77 was brought before the committee, by our own Ben Gamari I propose Manuel M T Chakravarty as the Shepherd. Roman, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From chak at justtesting.org Mon Nov 13 03:07:34 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Mon, 13 Nov 2017 14:07:34 +1100 Subject: [ghc-steering-committee] Our process and BIG ideas Message-ID: <2D6B8C27-49E0-49DE-A16F-CDC500123B13@justtesting.org> In the light of the linear types proposal PR, SimonPJ’s comment https://github.com/ghc-proposals/ghc-proposals/pull/91#issuecomment-343457821 and some uncertainty about the proposal process that has been communicated to me via a side channel, it might be worthwhile clarifying our expectations for large complex proposals. (I know, we basically punted on these questions in our initial discussion on the process with the intention to revisit after we gained some experience. It seems this time has come.) Firstly, we usually require proposals to be self-contained. This makes a lot of sense for small to medium-sized proposals to limit the time needed by the committee to hunt down all the required information. However, in a case, such as the linear types work, where there is a highly polished text in the form of a research paper (or similar), it seems reasonable to refer to that existing work — not only because type rules are a lot nicer to read when rendered by LaTeX instead of Markdown. Concretely, I’d like us to give some guidance wrt to this issue to proposal authors and document that at https://github.com/ghc-proposals/ghc-proposals#ghc-proposals Secondly, Simon, you seem to suggest that a large proposal like this wouldn’t be either accepted or rejected, but put into a kind a limbo state of further evaluation as seen fit. I agree that instead of outright rejection of a proposal that we consider flawed but not hopeless, we might request further elaboration and resubmission as we have done in the past. However, if a proposal passes muster, I think, we should accept it unconditionally, even if it is a large change. (If, say, at the end, the implementation is not up to scratch, then it is up to the code reviewers to reject the patches, but I don’t think, it is this committee’s job anymore.) In any case, I think, it is important make the process as clear as possible to authors, so they know what they are in for. What do you all think? Cheers, Manuel From rae at cs.brynmawr.edu Mon Nov 13 03:25:24 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Sun, 12 Nov 2017 22:25:24 -0500 Subject: [ghc-steering-committee] Our process and BIG ideas In-Reply-To: <2D6B8C27-49E0-49DE-A16F-CDC500123B13@justtesting.org> References: <2D6B8C27-49E0-49DE-A16F-CDC500123B13@justtesting.org> Message-ID: <76A54206-1B4E-4CE3-8527-7A110961BCF6@cs.brynmawr.edu> I fully agree that proposals for large new features can reference an accompanying paper. However, I'm leery of unconditional approval of something as large as the linear types proposal. GHC is a very large, complex system, and no one can anticipate all the interactions that a proposal may have with existing features. It's quite possible that something which seems like a good idea has a disastrous interaction with some other part of the compiler/language definition. Instead, I would favor a conditional approval that would turn to rejection only if further experience (gained through a [partial] implementation) reveals a theoretical sticking point. I use "theoretical" here to mean that the rejection wouldn't be based on poor code quality or an implementation challenge, per se, but by running into a scenario where we are unable to specify the correct behavior of the system. In truth, even an approval that we described as unconditional would really be as in the paragraph above -- we simply can't do better. So I guess I'm favoring calling such an approval as conditional, just to be clear to proposers what we mean. Richard > On Nov 12, 2017, at 10:07 PM, Manuel M T Chakravarty wrote: > > In the light of the linear types proposal PR, SimonPJ’s comment > > https://github.com/ghc-proposals/ghc-proposals/pull/91#issuecomment-343457821 > > and some uncertainty about the proposal process that has been communicated to me via a side channel, it might be worthwhile clarifying our expectations for large complex proposals. (I know, we basically punted on these questions in our initial discussion on the process with the intention to revisit after we gained some experience. It seems this time has come.) > > Firstly, we usually require proposals to be self-contained. This makes a lot of sense for small to medium-sized proposals to limit the time needed by the committee to hunt down all the required information. However, in a case, such as the linear types work, where there is a highly polished text in the form of a research paper (or similar), it seems reasonable to refer to that existing work — not only because type rules are a lot nicer to read when rendered by LaTeX instead of Markdown. > > Concretely, I’d like us to give some guidance wrt to this issue to proposal authors and document that at https://github.com/ghc-proposals/ghc-proposals#ghc-proposals > > Secondly, Simon, you seem to suggest that a large proposal like this wouldn’t be either accepted or rejected, but put into a kind a limbo state of further evaluation as seen fit. I agree that instead of outright rejection of a proposal that we consider flawed but not hopeless, we might request further elaboration and resubmission as we have done in the past. However, if a proposal passes muster, I think, we should accept it unconditionally, even if it is a large change. (If, say, at the end, the implementation is not up to scratch, then it is up to the code reviewers to reject the patches, but I don’t think, it is this committee’s job anymore.) > > In any case, I think, it is important make the process as clear as possible to authors, so they know what they are in for. > > What do you all think? > > Cheers, > Manuel > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From simonpj at microsoft.com Mon Nov 13 12:39:23 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 13 Nov 2017 12:39:23 +0000 Subject: [ghc-steering-committee] Our process and BIG ideas In-Reply-To: <76A54206-1B4E-4CE3-8527-7A110961BCF6@cs.brynmawr.edu> References: <2D6B8C27-49E0-49DE-A16F-CDC500123B13@justtesting.org> <76A54206-1B4E-4CE3-8527-7A110961BCF6@cs.brynmawr.edu> Message-ID: | However, I'm leery of unconditional approval of something as large as the | linear types proposal. If "unconditional approval" means " we agree to include this feature in GHC, regardless of the consequences", then I guess everyone would agree with Richard. It's not just the implementation consequences either: we have to think about the interaction of a big new feature with all the other aspects of the surface language, and that is really hard to do in advance. For little proposals (like commas in export lists) we can be pretty confident that we aren't going to get any major surprises. For big ones like this, our confidence is much lower. But we must think of it from the contributors' point of view too. Contributors to GHC want to see a transparent and somewhat predictable pipeline of steps that successively make it more and more likely that a proposal will end up in mainstream GHC. For big proposals maybe we need more steps. E.g. 1. Philosophically, we like the direction of travel. If there are no surprises, we'd like to have this in the language. 2. Details. Now there are lot of specifics. Interactions with other features of Haskell. If there are going to be changes in Core, a precise specification of those changes would be helpful. (I know that Core is an internal matter, but it's an outstandingly good sanity-check.) 3. Implementation. Now we have an implementation. 4. Merge into HEAD We have previously conflated (1) and (2) and that seems fine for a small proposal, but for a big one like this we might want to split the steps, to offer authors the confidence to invest in (2). Actually (2) and (3) are likely to be symbiotic, I think. Does that make sense? Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces at haskell.org] On Behalf Of Richard Eisenberg | Sent: 13 November 2017 03:25 | To: Manuel M T Chakravarty | Cc: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] Our process and BIG ideas | | I fully agree that proposals for large new features can reference an | accompanying paper. | | However, I'm leery of unconditional approval of something as large as the | linear types proposal. GHC is a very large, complex system, and no one can | anticipate all the interactions that a proposal may have with existing | features. It's quite possible that something which seems like a good idea | has a disastrous interaction with some other part of the compiler/language | definition. | | Instead, I would favor a conditional approval that would turn to rejection | only if further experience (gained through a [partial] implementation) | reveals a theoretical sticking point. I use "theoretical" here to mean that | the rejection wouldn't be based on poor code quality or an implementation | challenge, per se, but by running into a scenario where we are unable to | specify the correct behavior of the system. | | In truth, even an approval that we described as unconditional would really | be as in the paragraph above -- we simply can't do better. So I guess I'm | favoring calling such an approval as conditional, just to be clear to | proposers what we mean. | | Richard | | > On Nov 12, 2017, at 10:07 PM, Manuel M T Chakravarty | wrote: | > | > In the light of the linear types proposal PR, SimonPJ’s comment | > | > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% | 2Fghc-proposals%2Fghc-proposals%2Fpull%2F91%23issuecomment- | 343457821&data=02%7C01%7Csimonpj%40microsoft.com%7C76a50b24b6dc436c9c4808d52 | a463534%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636461403387929271&sdat | a=%2FGtP16v%2BiJEDwkd0TpX6yKpXS0bZaOh1HWDCEsPTiDg%3D&reserved=0 | > | > and some uncertainty about the proposal process that has been communicated | to me via a side channel, it might be worthwhile clarifying our expectations | for large complex proposals. (I know, we basically punted on these questions | in our initial discussion on the process with the intention to revisit after | we gained some experience. It seems this time has come.) | > | > Firstly, we usually require proposals to be self-contained. This makes a | lot of sense for small to medium-sized proposals to limit the time needed by | the committee to hunt down all the required information. However, in a case, | such as the linear types work, where there is a highly polished text in the | form of a research paper (or similar), it seems reasonable to refer to that | existing work — not only because type rules are a lot nicer to read when | rendered by LaTeX instead of Markdown. | > | > Concretely, I’d like us to give some guidance wrt to this issue to | proposal authors and document that at | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% | 2Fghc-proposals%2Fghc-proposals%23ghc- | proposals&data=02%7C01%7Csimonpj%40microsoft.com%7C76a50b24b6dc436c9c4808d52 | a463534%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636461403387929271&sdat | a=Z8x%2FqlkWGH4dt43vQYpU9yP7YGGBZ4NR920%2FBS6EMA4%3D&reserved=0 | > | > Secondly, Simon, you seem to suggest that a large proposal like this | wouldn’t be either accepted or rejected, but put into a kind a limbo state | of further evaluation as seen fit. I agree that instead of outright | rejection of a proposal that we consider flawed but not hopeless, we might | request further elaboration and resubmission as we have done in the past. | However, if a proposal passes muster, I think, we should accept it | unconditionally, even if it is a large change. (If, say, at the end, the | implementation is not up to scratch, then it is up to the code reviewers to | reject the patches, but I don’t think, it is this committee’s job anymore.) | > | > In any case, I think, it is important make the process as clear as | possible to authors, so they know what they are in for. | > | > What do you all think? | > | > Cheers, | > Manuel | > | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee at haskell.org | > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From rae at cs.brynmawr.edu Mon Nov 13 14:38:25 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 13 Nov 2017 09:38:25 -0500 Subject: [ghc-steering-committee] Our process and BIG ideas In-Reply-To: References: <2D6B8C27-49E0-49DE-A16F-CDC500123B13@justtesting.org> <76A54206-1B4E-4CE3-8527-7A110961BCF6@cs.brynmawr.edu> Message-ID: I like Simon’s steps below. Indeed, I’ve been wondering when/how to make my “Add dependent types to Haskell” proposal. By making a step (1) proposal, I could prepare that easily and early, allowing lots of time for people to warm up to the idea. Thinking about it more, I think this would solve a problem that came up just a few days ago: @andrewthad pointed out in my “visible dependent quantifier” proposal that several proposals floating around right now are all little slices of my ideas about adding dependent types. The proposals have merit by themselves (I think), and that’s why I’m proposing them. However, Andrew is right that it might make it all easier to understand in the context of the larger proposal. With Simon’s extra step, below, I could propose dependent types, writ large, and then link concrete proposals back to the grand, philosophical vision. At some point, there would be a big proposal to actually add the dependent types, but this structure would allow me to tell a more coherent story about the little pieces I’m laying down now as foundations. Richard > On Nov 13, 2017, at 7:39 AM, Simon Peyton Jones wrote: > > 1. Philosophically, we like the direction of travel. If there are no surprises, we'd like to have this in the language. > > 2. Details. Now there are lot of specifics. Interactions with other features of Haskell. If there are going to be changes in Core, a precise specification of those changes would be helpful. (I know that Core is an internal matter, but it's an outstandingly good sanity-check.) > > 3. Implementation. Now we have an implementation. > > 4. Merge into HEAD From chak at justtesting.org Tue Nov 14 01:10:12 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Tue, 14 Nov 2017 12:10:12 +1100 Subject: [ghc-steering-committee] Our process and BIG ideas In-Reply-To: References: <2D6B8C27-49E0-49DE-A16F-CDC500123B13@justtesting.org> <76A54206-1B4E-4CE3-8527-7A110961BCF6@cs.brynmawr.edu> Message-ID: All approval is conditional ~~~~~~~~~~~~~~~~~~~~ I get the feeling that this discussion is actually really about, > What does approval mean? Currently, the ghc-proposals' README states, > Acceptance of the proposal implies that the implementation will be accepted into GHC provided it is well-engineered, well-documented, and does not complicate the code-base too much. So, obviously and explicitly all acceptance of proposals by this committee is conditional (there is no unconditional approval). Everything is conditional on a good implementation. However, I would argue that —in actual fact— there are some conditions that we have never made explicit as well, and those implicit conditions are at the core of the current discussion. For example, proposals like TypeInType, linear types, or dependent types may well turn out to be impossible to implement *without complicating the code-base too much* (e.g., because they need to change Core in ways that are too intrusive). In other words, if the required engineering constraints are impossible to meet for a proposal, then, despite it originally being accepted, we wouldn’t allow it into a shipping compiler. I will go further and argue that there are conditions that are not mentioned at all. For example, let’s assume I make a convincing argument for a type extension and I have a conference paper and a proof of progress and preservation, and the committee accepts my proposal. If, during implementation, I or somebody else find that my proof is actually faulty and the system is unsound, would we allow it into the compiler only because we accepted the proposal? Of course not! Hence, all accepted proposals are also conditional on that the properties and assumptions stated in the proposal are actually correct. If a proposal claims that an extension is sound, it must be sound. If it states that it doesn’t conflict with other type extension, it may not conflict. If it argues, the implementation will be efficient, it must be efficient, and so on. If anything turns out to be wrong, the approval, which was issued under these assumptions, is void. (Think of it as a contract that is voided once any of the clauses is violated.) So, I hope we can agree that all approval is conditional. What we need to do is to specify the conditions that we implicitly assign beyond the engineering focused condition that is currently in the README. (Having conditions is fine, but to be fair to proposal authors, IMHO we need to be explicit about them.) Size doesn’t matter ~~~~~~~~~~~~~~~ I like to argue that the size of a proposal is much less important than we might think. Fairly small changes can easily turn into a pit of vipers. For example, take generalised new type deriving. It was such a small simple change and easy to do with System FC’s equality constraints. If we had had GHC proposals at the time, this would have been a small proposal relative to the fancy type family additions and GADTs going on at the time. Nevertheless, I’d argue, generalised newtype deriving was probably the biggest type soundness nightmare GHC ever had. (How many papers did it take to fix it…kind of?) Whether a proposal is long or short, whether it involves complex types, or whether it is just syntax (that may always turn out to be really hard to implement with LALR(1)), I think, we want the same rules and the same conditions attached to approval of the proposal. * There needs to a well-engineered implementation. * It shouldn’t complicate the codebase too much. * It must not have unexpected interactions with other language features. * It must not unduly affect the performance of the compiler (neither of compilation nor of the generated code). * It must not turn out to be unsound. * It must not turn out to lead to impossible to understand error messages. * What else? All these conditions must be met by *all* proposals, large or small. Every approval is always conditional on all of these conditions. What if a condition is violated ~~~~~~~~~~~~~~~~~~~~~~ That depends on whether the problem can be fixed and what kind of fix is needed. Anything that is ”just” a matter of code quality is a matter for the code reviewers to hold back until it is good enough. Anything destabilising the compiler or turning out to affect performance too much is up to the release manager to prevent going into an actual release. These issues are not a concern of this committee. However, if a conceptual problem is found, a system is unsound, or generally any of the assumptions or statements in the proposal *on which approval was based* turns out to be wrong, the proposal needs to be changed. Once it is changed, it needs to be approved again. If no acceptable change can be found, the proposal is out. Summary ~~~~~~~ I propose to make the conditions (that always existed) explicit, check them while a proposal gets refined and potential issues discovered during implementation, and bounce any (significant) changes that need to be made back to the committee. In this way, I hope, we can address the concerns voiced by Simon and Richard, while being completely transparent to proposal authors. Moreover, we don’t need any a priori judgement about whether a proposal is small or large (and where exactly is that boundary). Instead, naturally, anything that leads to issues will be sent back to the committee, which allows for iteration exactly where this is necessary. Cheers, Manuel > Simon Peyton Jones : > > | However, I'm leery of unconditional approval of something as large as the > | linear types proposal. > > If "unconditional approval" means " we agree to include this feature in GHC, regardless of the consequences", then I guess everyone would agree with Richard. It's not just the implementation consequences either: we have to think about the interaction of a big new feature with all the other aspects of the surface language, and that is really hard to do in advance. > > For little proposals (like commas in export lists) we can be pretty confident that we aren't going to get any major surprises. For big ones like this, our confidence is much lower. > > But we must think of it from the contributors' point of view too. Contributors to GHC want to see a transparent and somewhat predictable pipeline of steps that successively make it more and more likely that a proposal will end up in mainstream GHC. For big proposals maybe we need more steps. E.g. > > 1. Philosophically, we like the direction of travel. If there are no surprises, we'd like to have this in the language. > > 2. Details. Now there are lot of specifics. Interactions with other features of Haskell. If there are going to be changes in Core, a precise specification of those changes would be helpful. (I know that Core is an internal matter, but it's an outstandingly good sanity-check.) > > 3. Implementation. Now we have an implementation. > > 4. Merge into HEAD > > We have previously conflated (1) and (2) and that seems fine for a small proposal, but for a big one like this we might want to split the steps, to offer authors the confidence to invest in (2). > > Actually (2) and (3) are likely to be symbiotic, I think. > > Does that make sense? > > Simon > > | -----Original Message----- > | From: ghc-steering-committee [mailto:ghc-steering-committee- > | bounces at haskell.org] On Behalf Of Richard Eisenberg > | Sent: 13 November 2017 03:25 > | To: Manuel M T Chakravarty > | Cc: ghc-steering-committee at haskell.org > | Subject: Re: [ghc-steering-committee] Our process and BIG ideas > | > | I fully agree that proposals for large new features can reference an > | accompanying paper. > | > | However, I'm leery of unconditional approval of something as large as the > | linear types proposal. GHC is a very large, complex system, and no one can > | anticipate all the interactions that a proposal may have with existing > | features. It's quite possible that something which seems like a good idea > | has a disastrous interaction with some other part of the compiler/language > | definition. > | > | Instead, I would favor a conditional approval that would turn to rejection > | only if further experience (gained through a [partial] implementation) > | reveals a theoretical sticking point. I use "theoretical" here to mean that > | the rejection wouldn't be based on poor code quality or an implementation > | challenge, per se, but by running into a scenario where we are unable to > | specify the correct behavior of the system. > | > | In truth, even an approval that we described as unconditional would really > | be as in the paragraph above -- we simply can't do better. So I guess I'm > | favoring calling such an approval as conditional, just to be clear to > | proposers what we mean. > | > | Richard > | > | > On Nov 12, 2017, at 10:07 PM, Manuel M T Chakravarty > | wrote: > | > > | > In the light of the linear types proposal PR, SimonPJ’s comment > | > > | > > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% > | 2Fghc-proposals%2Fghc-proposals%2Fpull%2F91%23issuecomment- > | 343457821&data=02%7C01%7Csimonpj%40microsoft.com%7C76a50b24b6dc436c9c4808d52 > | a463534%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636461403387929271&sdat > | a=%2FGtP16v%2BiJEDwkd0TpX6yKpXS0bZaOh1HWDCEsPTiDg%3D&reserved=0 > | > > | > and some uncertainty about the proposal process that has been communicated > | to me via a side channel, it might be worthwhile clarifying our expectations > | for large complex proposals. (I know, we basically punted on these questions > | in our initial discussion on the process with the intention to revisit after > | we gained some experience. It seems this time has come.) > | > > | > Firstly, we usually require proposals to be self-contained. This makes a > | lot of sense for small to medium-sized proposals to limit the time needed by > | the committee to hunt down all the required information. However, in a case, > | such as the linear types work, where there is a highly polished text in the > | form of a research paper (or similar), it seems reasonable to refer to that > | existing work — not only because type rules are a lot nicer to read when > | rendered by LaTeX instead of Markdown. > | > > | > Concretely, I’d like us to give some guidance wrt to this issue to > | proposal authors and document that at > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% > | 2Fghc-proposals%2Fghc-proposals%23ghc- > | proposals&data=02%7C01%7Csimonpj%40microsoft.com%7C76a50b24b6dc436c9c4808d52 > | a463534%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636461403387929271&sdat > | a=Z8x%2FqlkWGH4dt43vQYpU9yP7YGGBZ4NR920%2FBS6EMA4%3D&reserved=0 > | > > | > Secondly, Simon, you seem to suggest that a large proposal like this > | wouldn’t be either accepted or rejected, but put into a kind a limbo state > | of further evaluation as seen fit. I agree that instead of outright > | rejection of a proposal that we consider flawed but not hopeless, we might > | request further elaboration and resubmission as we have done in the past. > | However, if a proposal passes muster, I think, we should accept it > | unconditionally, even if it is a large change. (If, say, at the end, the > | implementation is not up to scratch, then it is up to the code reviewers to > | reject the patches, but I don’t think, it is this committee’s job anymore.) > | > > | > In any case, I think, it is important make the process as clear as > | possible to authors, so they know what they are in for. > | > > | > What do you all think? > | > > | > Cheers, > | > Manuel > | > > | > _______________________________________________ > | > ghc-steering-committee mailing list > | > ghc-steering-committee at haskell.org > | > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > | > | _______________________________________________ > | ghc-steering-committee mailing list > | ghc-steering-committee at haskell.org > | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Nov 14 09:12:01 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 14 Nov 2017 09:12:01 +0000 Subject: [ghc-steering-committee] Our process and BIG ideas In-Reply-To: References: <2D6B8C27-49E0-49DE-A16F-CDC500123B13@justtesting.org> <76A54206-1B4E-4CE3-8527-7A110961BCF6@cs.brynmawr.edu> Message-ID: I’m ok with what Manuel says, especially the bit about being more explicit about the implicit conditionality. But I would add * Acceptance is always a balance of judgement. Is the extra language and implementation complexity justified by the benefits to the programmer? For “big” features, that balance may change as we learn more about it. Manuel takes outright unsoundness as an example, and it is a comforting one because it’s so clear-cut. But in reality I think that it’s more likely that there’ll be a slow accretion of hidden costs that slowly become apparent. Then it might seem more capricious if the committee’s judgement changed; and in any case there’d be no moment at which the committee was asked to review the proposal in the light of experience. * I think we could address some of this by making the conditionality in acceptance more explicit, just as Manuel says. But in specific terms, not just in general ones. For example, for or-patterns I think we are edging towards “accept, provided we can resolve the issues around GADTs etc”. For a “bigger” proposal we might have a longer list of things we regarded as danger spots. * I suggest that we add to our criteria what effect (if any) the proposal has on Core. You may see Core as merely an implementation mechanism, but I regard it as a solid sanity check. We simply do not have a formal specification for all of Haskell. It’s too big, and if we insisted on that we ‘d never do anything. But we DO have a formal spec for Core. It is small enough to be intellectually tractable. And, for better or worse, GHC is one of the very few production compilers in the world (I actually do now know of any others) that maintain a statically typed IR right through optimisation up to code generation. Most proposals don’t change Core one whit. But for those that do, I think it would be reasonable to ask for a pretty solid spec of what changes are proposed. That would reassure us that the proposal is in fact sound. All the rest is syntactic sugar, as it were. Simon From: Manuel M T Chakravarty [mailto:chak at justtesting.org] Sent: 14 November 2017 01:10 To: Simon Peyton Jones Cc: Richard Eisenberg ; ghc-steering-committee at haskell.org Subject: Re: [ghc-steering-committee] Our process and BIG ideas All approval is conditional ~~~~~~~~~~~~~~~~~~~~ I get the feeling that this discussion is actually really about, > What does approval mean? Currently, the ghc-proposals' README states, Acceptance of the proposal implies that the implementation will be accepted into GHC provided it is well-engineered, well-documented, and does not complicate the code-base too much. So, obviously and explicitly all acceptance of proposals by this committee is conditional (there is no unconditional approval). Everything is conditional on a good implementation. However, I would argue that —in actual fact— there are some conditions that we have never made explicit as well, and those implicit conditions are at the core of the current discussion. For example, proposals like TypeInType, linear types, or dependent types may well turn out to be impossible to implement *without complicating the code-base too much* (e.g., because they need to change Core in ways that are too intrusive). In other words, if the required engineering constraints are impossible to meet for a proposal, then, despite it originally being accepted, we wouldn’t allow it into a shipping compiler. I will go further and argue that there are conditions that are not mentioned at all. For example, let’s assume I make a convincing argument for a type extension and I have a conference paper and a proof of progress and preservation, and the committee accepts my proposal. If, during implementation, I or somebody else find that my proof is actually faulty and the system is unsound, would we allow it into the compiler only because we accepted the proposal? Of course not! Hence, all accepted proposals are also conditional on that the properties and assumptions stated in the proposal are actually correct. If a proposal claims that an extension is sound, it must be sound. If it states that it doesn’t conflict with other type extension, it may not conflict. If it argues, the implementation will be efficient, it must be efficient, and so on. If anything turns out to be wrong, the approval, which was issued under these assumptions, is void. (Think of it as a contract that is voided once any of the clauses is violated.) So, I hope we can agree that all approval is conditional. What we need to do is to specify the conditions that we implicitly assign beyond the engineering focused condition that is currently in the README. (Having conditions is fine, but to be fair to proposal authors, IMHO we need to be explicit about them.) Size doesn’t matter ~~~~~~~~~~~~~~~ I like to argue that the size of a proposal is much less important than we might think. Fairly small changes can easily turn into a pit of vipers. For example, take generalised new type deriving. It was such a small simple change and easy to do with System FC’s equality constraints. If we had had GHC proposals at the time, this would have been a small proposal relative to the fancy type family additions and GADTs going on at the time. Nevertheless, I’d argue, generalised newtype deriving was probably the biggest type soundness nightmare GHC ever had. (How many papers did it take to fix it…kind of?) Whether a proposal is long or short, whether it involves complex types, or whether it is just syntax (that may always turn out to be really hard to implement with LALR(1)), I think, we want the same rules and the same conditions attached to approval of the proposal. * There needs to a well-engineered implementation. * It shouldn’t complicate the codebase too much. * It must not have unexpected interactions with other language features. * It must not unduly affect the performance of the compiler (neither of compilation nor of the generated code). * It must not turn out to be unsound. * It must not turn out to lead to impossible to understand error messages. * What else? All these conditions must be met by *all* proposals, large or small. Every approval is always conditional on all of these conditions. What if a condition is violated ~~~~~~~~~~~~~~~~~~~~~~ That depends on whether the problem can be fixed and what kind of fix is needed. Anything that is ”just” a matter of code quality is a matter for the code reviewers to hold back until it is good enough. Anything destabilising the compiler or turning out to affect performance too much is up to the release manager to prevent going into an actual release. These issues are not a concern of this committee. However, if a conceptual problem is found, a system is unsound, or generally any of the assumptions or statements in the proposal *on which approval was based* turns out to be wrong, the proposal needs to be changed. Once it is changed, it needs to be approved again. If no acceptable change can be found, the proposal is out. Summary ~~~~~~~ I propose to make the conditions (that always existed) explicit, check them while a proposal gets refined and potential issues discovered during implementation, and bounce any (significant) changes that need to be made back to the committee. In this way, I hope, we can address the concerns voiced by Simon and Richard, while being completely transparent to proposal authors. Moreover, we don’t need any a priori judgement about whether a proposal is small or large (and where exactly is that boundary). Instead, naturally, anything that leads to issues will be sent back to the committee, which allows for iteration exactly where this is necessary. Cheers, Manuel Simon Peyton Jones >: | However, I'm leery of unconditional approval of something as large as the | linear types proposal. If "unconditional approval" means " we agree to include this feature in GHC, regardless of the consequences", then I guess everyone would agree with Richard. It's not just the implementation consequences either: we have to think about the interaction of a big new feature with all the other aspects of the surface language, and that is really hard to do in advance. For little proposals (like commas in export lists) we can be pretty confident that we aren't going to get any major surprises. For big ones like this, our confidence is much lower. But we must think of it from the contributors' point of view too. Contributors to GHC want to see a transparent and somewhat predictable pipeline of steps that successively make it more and more likely that a proposal will end up in mainstream GHC. For big proposals maybe we need more steps. E.g. 1. Philosophically, we like the direction of travel. If there are no surprises, we'd like to have this in the language. 2. Details. Now there are lot of specifics. Interactions with other features of Haskell. If there are going to be changes in Core, a precise specification of those changes would be helpful. (I know that Core is an internal matter, but it's an outstandingly good sanity-check.) 3. Implementation. Now we have an implementation. 4. Merge into HEAD We have previously conflated (1) and (2) and that seems fine for a small proposal, but for a big one like this we might want to split the steps, to offer authors the confidence to invest in (2). Actually (2) and (3) are likely to be symbiotic, I think. Does that make sense? Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces at haskell.org] On Behalf Of Richard Eisenberg | Sent: 13 November 2017 03:25 | To: Manuel M T Chakravarty > | Cc: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] Our process and BIG ideas | | I fully agree that proposals for large new features can reference an | accompanying paper. | | However, I'm leery of unconditional approval of something as large as the | linear types proposal. GHC is a very large, complex system, and no one can | anticipate all the interactions that a proposal may have with existing | features. It's quite possible that something which seems like a good idea | has a disastrous interaction with some other part of the compiler/language | definition. | | Instead, I would favor a conditional approval that would turn to rejection | only if further experience (gained through a [partial] implementation) | reveals a theoretical sticking point. I use "theoretical" here to mean that | the rejection wouldn't be based on poor code quality or an implementation | challenge, per se, but by running into a scenario where we are unable to | specify the correct behavior of the system. | | In truth, even an approval that we described as unconditional would really | be as in the paragraph above -- we simply can't do better. So I guess I'm | favoring calling such an approval as conditional, just to be clear to | proposers what we mean. | | Richard | | > On Nov 12, 2017, at 10:07 PM, Manuel M T Chakravarty | > wrote: | > | > In the light of the linear types proposal PR, SimonPJ’s comment | > | > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% | 2Fghc-proposals%2Fghc-proposals%2Fpull%2F91%23issuecomment- | 343457821&data=02%7C01%7Csimonpj%40microsoft.com%7C76a50b24b6dc436c9c4808d52 | a463534%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636461403387929271&sdat | a=%2FGtP16v%2BiJEDwkd0TpX6yKpXS0bZaOh1HWDCEsPTiDg%3D&reserved=0 | > | > and some uncertainty about the proposal process that has been communicated | to me via a side channel, it might be worthwhile clarifying our expectations | for large complex proposals. (I know, we basically punted on these questions | in our initial discussion on the process with the intention to revisit after | we gained some experience. It seems this time has come.) | > | > Firstly, we usually require proposals to be self-contained. This makes a | lot of sense for small to medium-sized proposals to limit the time needed by | the committee to hunt down all the required information. However, in a case, | such as the linear types work, where there is a highly polished text in the | form of a research paper (or similar), it seems reasonable to refer to that | existing work — not only because type rules are a lot nicer to read when | rendered by LaTeX instead of Markdown. | > | > Concretely, I’d like us to give some guidance wrt to this issue to | proposal authors and document that at | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% | 2Fghc-proposals%2Fghc-proposals%23ghc- | proposals&data=02%7C01%7Csimonpj%40microsoft.com%7C76a50b24b6dc436c9c4808d52 | a463534%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636461403387929271&sdat | a=Z8x%2FqlkWGH4dt43vQYpU9yP7YGGBZ4NR920%2FBS6EMA4%3D&reserved=0 | > | > Secondly, Simon, you seem to suggest that a large proposal like this | wouldn’t be either accepted or rejected, but put into a kind a limbo state | of further evaluation as seen fit. I agree that instead of outright | rejection of a proposal that we consider flawed but not hopeless, we might | request further elaboration and resubmission as we have done in the past. | However, if a proposal passes muster, I think, we should accept it | unconditionally, even if it is a large change. (If, say, at the end, the | implementation is not up to scratch, then it is up to the code reviewers to | reject the patches, but I don’t think, it is this committee’s job anymore.) | > | > In any case, I think, it is important make the process as clear as | possible to authors, so they know what they are in for. | > | > What do you all think? | > | > Cheers, | > Manuel | > | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee at haskell.org | > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Tue Nov 14 18:03:47 2017 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 14 Nov 2017 18:03:47 +0000 Subject: [ghc-steering-committee] Underscores in literals In-Reply-To: References: Message-ID: Hello, I am not hearing any objections about this, so I am going to mark it as accepted. -Iavor On Tue, Nov 7, 2017 at 10:56 AM Simon Peyton Jones wrote: > I’m ok with this, although I have not thought deeply about the details. > > > > Simon > > > > *From:* ghc-steering-committee [mailto: > ghc-steering-committee-bounces at haskell.org] *On Behalf Of *Iavor Diatchki > *Sent:* 07 November 2017 18:12 > *To:* ghc-steering-committee at haskell.org > *Subject:* [ghc-steering-committee] Underscores in literals > > > > Hello, > > > > This e-mail is about pull request #76, to allow underscores in numeric > literals: > > > > > https://github.com/takenobu-hs/ghc-proposals/blob/numeric-underscores/proposals/0000-numeric-underscores.rst > > > > > In short, this is a very simply feature, which modifies the notation for > numeric literals to allow writing underscores (_) in the middle of > literals. The underscores are only to increase readability, and have no > effect on the meaning of the program. So, for example, I could write > things like: 10_000_072 or 0xFFFF_FA10. > > > > Many other languages have a similar feature (especially hardware > specification languages) and I see no downsides to it, so I think we should > accept it. > > > > Please respond to this e-mail if you have objections. > > > > Cheers, > > -Iavor > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Tue Nov 14 19:55:10 2017 From: ben at well-typed.com (Ben Gamari) Date: Tue, 14 Nov 2017 14:55:10 -0500 Subject: [ghc-steering-committee] Underscores in literals In-Reply-To: References: Message-ID: <87efp0ljom.fsf@ben-laptop.smart-cactus.org> Iavor Diatchki writes: > Hello, > > I am not hearing any objections about this, so I am going to mark it as > accepted. > Yes, I for one would love to have this. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From chak at justtesting.org Tue Nov 14 22:28:35 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Wed, 15 Nov 2017 09:28:35 +1100 Subject: [ghc-steering-committee] Underscores in literals In-Reply-To: <87efp0ljom.fsf@ben-laptop.smart-cactus.org> References: <87efp0ljom.fsf@ben-laptop.smart-cactus.org> Message-ID: +1 > Ben Gamari : > > Iavor Diatchki writes: > >> Hello, >> >> I am not hearing any objections about this, so I am going to mark it as >> accepted. >> > Yes, I for one would love to have this. > > Cheers, > > - Ben > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From chak at justtesting.org Wed Nov 15 02:25:49 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Wed, 15 Nov 2017 13:25:49 +1100 Subject: [ghc-steering-committee] Our process and BIG ideas In-Reply-To: References: <2D6B8C27-49E0-49DE-A16F-CDC500123B13@justtesting.org> <76A54206-1B4E-4CE3-8527-7A110961BCF6@cs.brynmawr.edu> Message-ID: Simon, I think, the suggestion to add a formal point about detailing the effect of an extension on Core is fabulous! We should absolutely do that. It seems the sticky point is your first, the slow accretion of hidden costs. It totally agree that this is the most tricky scenario. However, I am not so sure that there is no moment, where that costs are checked. There is none if we look at this committee in isolation. However, there is one if we look at the entire process of getting an extension into GHC (and I think, this is key to making this all work elegantly). Here is the pipeline: Proposal | v [1] (GHC Steering Committee) | Pull Request/Differential | v [2] (Code reviewers) | Development version | v [3] (Release Manager) | v Released feature For anything to get into a stable release, there are three checks [1], [2] & [3] that need to be passed. What I propose is that failure to pass one of the checks doesn’t just prevent you from getting further, but that it may throw you back to an earlier stage. In the proposal, we do ask about the implementation costs and costs of feature interaction etc. I like to suggest that if a code contribution backed by a proposal is submitted for consideration for merging, the code reviewers check that the code contribution actually meets the promises made in the proposal about, for example, implementation costs. If these promises are not met, there are two possibilities: (a) The implementation is just not very good. In that case, the contributors can try to improve their code and try again. (b) The implementation is good, but the implementation turned out to be more costly than originally anticipated. In this case, code review will ask the contributor to revise their proposal, go back to the GHC Steering Committee, and get the revision approved. Now, this is the moment where the committee is asked to review the proposal in the light of the newly gained experience. For example, following your suggestion about explicitly asking proposal authors to detail the impact of an extension on Core. A proposal may claim to not have to change Core at all. Then, it turns out the implementation actually does change Core, maybe just in a small way. Nevertheless, this clearly signals to code review that the proposal was inaccurate. Hence, the proposal has to go back to the GHC Steering Committee and be re-approved. As another example, assume that we have got a big complex proposal and the authors write that they are —at this stage— unsure about the exact impact on Core. In this case, just as with the or-patterns and GADTs, we may review the proposal, but make final approval contingent on understanding the actual impact on Core. In this manner, the committee gets to re-check proposals, where substantial new experience was gained during the implementation that altered trade offs of implementation costs, feature interaction etc. Nevertheless, we do *not* need a priori and inherently imprecise evaluation of whether a proposal is ”big” or complex. In fact, our process (the whole pipeline above) is adaptive. The less accurate a proposal turns out to be (due to complexity or other factors), the more often it’ll be thrown back and re-evaluated. And maybe the fact that a proposal is thrown back multiple times will make us weary of it and cause us to eventually reject it. Manuel > Simon Peyton Jones : > > I’m ok with what Manuel says, especially the bit about being more explicit about the implicit conditionality. But I would add > > Acceptance is always a balance of judgement. Is the extra language and implementation complexity justified by the benefits to the programmer? For “big” features, that balance may change as we learn more about it. > > Manuel takes outright unsoundness as an example, and it is a comforting one because it’s so clear-cut. But in reality I think that it’s more likely that there’ll be a slow accretion of hidden costs that slowly become apparent. Then it might seem more capricious if the committee’s judgement changed; and in any case there’d be no moment at which the committee was asked to review the proposal in the light of experience. > > I think we could address some of this by making the conditionality in acceptance more explicit, just as Manuel says. But in specific terms, not just in general ones. For example, for or-patterns I think we are edging towards “accept, provided we can resolve the issues around GADTs etc”. For a “bigger” proposal we might have a longer list of things we regarded as danger spots. > > I suggest that we add to our criteria what effect (if any) the proposal has on Core. You may see Core as merely an implementation mechanism, but I regard it as a solid sanity check. We simply do not have a formal specification for all of Haskell. It’s too big, and if we insisted on that we ‘d never do anything. But we DO have a formal spec for Core . It is small enough to be intellectually tractable. And, for better or worse, GHC is one of the very few production compilers in the world (I actually do now know of any others) that maintain a statically typed IR right through optimisation up to code generation. > > Most proposals don’t change Core one whit. But for those that do, I think it would be reasonable to ask for a pretty solid spec of what changes are proposed. That would reassure us that the proposal is in fact sound. All the rest is syntactic sugar, as it were. > > Simon > > From: Manuel M T Chakravarty [mailto:chak at justtesting.org] > Sent: 14 November 2017 01:10 > To: Simon Peyton Jones > Cc: Richard Eisenberg ; ghc-steering-committee at haskell.org > Subject: Re: [ghc-steering-committee] Our process and BIG ideas > > All approval is conditional > ~~~~~~~~~~~~~~~~~~~~ > I get the feeling that this discussion is actually really about, > > > What does approval mean? > > Currently, the ghc-proposals' README states, > > Acceptance of the proposal implies that the implementation will be accepted into GHC provided it is well-engineered, well-documented, and does not complicate the code-base too much. > > So, obviously and explicitly all acceptance of proposals by this committee is conditional (there is no unconditional approval). Everything is conditional on a good implementation. > > However, I would argue that —in actual fact— there are some conditions that we have never made explicit as well, and those implicit conditions are at the core of the current discussion. For example, proposals like TypeInType, linear types, or dependent types may well turn out to be impossible to implement *without complicating the code-base too much* (e.g., because they need to change Core in ways that are too intrusive). In other words, if the required engineering constraints are impossible to meet for a proposal, then, despite it originally being accepted, we wouldn’t allow it into a shipping compiler. > > I will go further and argue that there are conditions that are not mentioned at all. For example, let’s assume I make a convincing argument for a type extension and I have a conference paper and a proof of progress and preservation, and the committee accepts my proposal. If, during implementation, I or somebody else find that my proof is actually faulty and the system is unsound, would we allow it into the compiler only because we accepted the proposal? Of course not! > > Hence, all accepted proposals are also conditional on that the properties and assumptions stated in the proposal are actually correct. If a proposal claims that an extension is sound, it must be sound. If it states that it doesn’t conflict with other type extension, it may not conflict. If it argues, the implementation will be efficient, it must be efficient, and so on. If anything turns out to be wrong, the approval, which was issued under these assumptions, is void. (Think of it as a contract that is voided once any of the clauses is violated.) > > So, I hope we can agree that all approval is conditional. What we need to do is to specify the conditions that we implicitly assign beyond the engineering focused condition that is currently in the README. (Having conditions is fine, but to be fair to proposal authors, IMHO we need to be explicit about them.) > > > Size doesn’t matter > ~~~~~~~~~~~~~~~ > I like to argue that the size of a proposal is much less important than we might think. Fairly small changes can easily turn into a pit of vipers. For example, take generalised new type deriving. It was such a small simple change and easy to do with System FC’s equality constraints. If we had had GHC proposals at the time, this would have been a small proposal relative to the fancy type family additions and GADTs going on at the time. Nevertheless, I’d argue, generalised newtype deriving was probably the biggest type soundness nightmare GHC ever had. (How many papers did it take to fix it…kind of?) > > Whether a proposal is long or short, whether it involves complex types, or whether it is just syntax (that may always turn out to be really hard to implement with LALR(1)), I think, we want the same rules and the same conditions attached to approval of the proposal. > > * There needs to a well-engineered implementation. > * It shouldn’t complicate the codebase too much. > * It must not have unexpected interactions with other language features. > * It must not unduly affect the performance of the compiler (neither of compilation nor of the generated code). > * It must not turn out to be unsound. > * It must not turn out to lead to impossible to understand error messages. > * What else? > > All these conditions must be met by *all* proposals, large or small. Every approval is always conditional on all of these conditions. > > > What if a condition is violated > ~~~~~~~~~~~~~~~~~~~~~~ > That depends on whether the problem can be fixed and what kind of fix is needed. > > Anything that is ”just” a matter of code quality is a matter for the code reviewers to hold back until it is good enough. Anything destabilising the compiler or turning out to affect performance too much is up to the release manager to prevent going into an actual release. These issues are not a concern of this committee. > > However, if a conceptual problem is found, a system is unsound, or generally any of the assumptions or statements in the proposal *on which approval was based* turns out to be wrong, the proposal needs to be changed. Once it is changed, it needs to be approved again. If no acceptable change can be found, the proposal is out. > > > Summary > ~~~~~~~ > I propose to make the conditions (that always existed) explicit, check them while a proposal gets refined and potential issues discovered during implementation, and bounce any (significant) changes that need to be made back to the committee. In this way, I hope, we can address the concerns voiced by Simon and Richard, while being completely transparent to proposal authors. > > Moreover, we don’t need any a priori judgement about whether a proposal is small or large (and where exactly is that boundary). Instead, naturally, anything that leads to issues will be sent back to the committee, which allows for iteration exactly where this is necessary. > > Cheers, > Manuel > > > Simon Peyton Jones >: > > | However, I'm leery of unconditional approval of something as large as the > | linear types proposal. > > If "unconditional approval" means " we agree to include this feature in GHC, regardless of the consequences", then I guess everyone would agree with Richard. It's not just the implementation consequences either: we have to think about the interaction of a big new feature with all the other aspects of the surface language, and that is really hard to do in advance. > > For little proposals (like commas in export lists) we can be pretty confident that we aren't going to get any major surprises. For big ones like this, our confidence is much lower. > > But we must think of it from the contributors' point of view too. Contributors to GHC want to see a transparent and somewhat predictable pipeline of steps that successively make it more and more likely that a proposal will end up in mainstream GHC. For big proposals maybe we need more steps. E.g. > > 1. Philosophically, we like the direction of travel. If there are no surprises, we'd like to have this in the language. > > 2. Details. Now there are lot of specifics. Interactions with other features of Haskell. If there are going to be changes in Core, a precise specification of those changes would be helpful. (I know that Core is an internal matter, but it's an outstandingly good sanity-check.) > > 3. Implementation. Now we have an implementation. > > 4. Merge into HEAD > > We have previously conflated (1) and (2) and that seems fine for a small proposal, but for a big one like this we might want to split the steps, to offer authors the confidence to invest in (2). > > Actually (2) and (3) are likely to be symbiotic, I think. > > Does that make sense? > > Simon > > | -----Original Message----- > | From: ghc-steering-committee [mailto:ghc-steering-committee- > | bounces at haskell.org ] On Behalf Of Richard Eisenberg > | Sent: 13 November 2017 03:25 > | To: Manuel M T Chakravarty > > | Cc: ghc-steering-committee at haskell.org > | Subject: Re: [ghc-steering-committee] Our process and BIG ideas > | > | I fully agree that proposals for large new features can reference an > | accompanying paper. > | > | However, I'm leery of unconditional approval of something as large as the > | linear types proposal. GHC is a very large, complex system, and no one can > | anticipate all the interactions that a proposal may have with existing > | features. It's quite possible that something which seems like a good idea > | has a disastrous interaction with some other part of the compiler/language > | definition. > | > | Instead, I would favor a conditional approval that would turn to rejection > | only if further experience (gained through a [partial] implementation) > | reveals a theoretical sticking point. I use "theoretical" here to mean that > | the rejection wouldn't be based on poor code quality or an implementation > | challenge, per se, but by running into a scenario where we are unable to > | specify the correct behavior of the system. > | > | In truth, even an approval that we described as unconditional would really > | be as in the paragraph above -- we simply can't do better. So I guess I'm > | favoring calling such an approval as conditional, just to be clear to > | proposers what we mean. > | > | Richard > | > | > On Nov 12, 2017, at 10:07 PM, Manuel M T Chakravarty > | > wrote: > | > > | > In the light of the linear types proposal PR, SimonPJ’s comment > | > > | > > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% > | 2Fghc-proposals%2Fghc-proposals%2Fpull%2F91%23issuecomment- > | 343457821&data=02%7C01%7Csimonpj%40microsoft.com %7C76a50b24b6dc436c9c4808d52 > | a463534%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636461403387929271&sdat > | a=%2FGtP16v%2BiJEDwkd0TpX6yKpXS0bZaOh1HWDCEsPTiDg%3D&reserved=0 > | > > | > and some uncertainty about the proposal process that has been communicated > | to me via a side channel, it might be worthwhile clarifying our expectations > | for large complex proposals. (I know, we basically punted on these questions > | in our initial discussion on the process with the intention to revisit after > | we gained some experience. It seems this time has come.) > | > > | > Firstly, we usually require proposals to be self-contained. This makes a > | lot of sense for small to medium-sized proposals to limit the time needed by > | the committee to hunt down all the required information. However, in a case, > | such as the linear types work, where there is a highly polished text in the > | form of a research paper (or similar), it seems reasonable to refer to that > | existing work — not only because type rules are a lot nicer to read when > | rendered by LaTeX instead of Markdown. > | > > | > Concretely, I’d like us to give some guidance wrt to this issue to > | proposal authors and document that at > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% > | 2Fghc-proposals%2Fghc-proposals%23ghc- > | proposals&data=02%7C01%7Csimonpj%40microsoft.com %7C76a50b24b6dc436c9c4808d52 > | a463534%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636461403387929271&sdat > | a=Z8x%2FqlkWGH4dt43vQYpU9yP7YGGBZ4NR920%2FBS6EMA4%3D&reserved=0 > | > > | > Secondly, Simon, you seem to suggest that a large proposal like this > | wouldn’t be either accepted or rejected, but put into a kind a limbo state > | of further evaluation as seen fit. I agree that instead of outright > | rejection of a proposal that we consider flawed but not hopeless, we might > | request further elaboration and resubmission as we have done in the past. > | However, if a proposal passes muster, I think, we should accept it > | unconditionally, even if it is a large change. (If, say, at the end, the > | implementation is not up to scratch, then it is up to the code reviewers to > | reject the patches, but I don’t think, it is this committee’s job anymore.) > | > > | > In any case, I think, it is important make the process as clear as > | possible to authors, so they know what they are in for. > | > > | > What do you all think? > | > > | > Cheers, > | > Manuel > | > > | > _______________________________________________ > | > ghc-steering-committee mailing list > | > ghc-steering-committee at haskell.org > | > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > | > | _______________________________________________ > | ghc-steering-committee mailing list > | ghc-steering-committee at haskell.org > | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Nov 15 09:38:58 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 15 Nov 2017 09:38:58 +0000 Subject: [ghc-steering-committee] Our process and BIG ideas In-Reply-To: References: <2D6B8C27-49E0-49DE-A16F-CDC500123B13@justtesting.org> <76A54206-1B4E-4CE3-8527-7A110961BCF6@cs.brynmawr.edu> Message-ID: I’m basically with you, but I do think that check [2] is qualitatively different to [1]. You say (b) The implementation is good, but the implementation turned out to be more costly than originally anticipated. In this case, code review will ask the contributor to revise their proposal, go back to the GHC Steering Committee, and get the revision approved. Now, this is the moment where the committee is asked to review the proposal in the light of the newly gained experience. My concern about the slow accretion of hidden costs is more about the [1] than [2]. In principle, an implementation could be simple, while yet imposing previously unanticipated complexity on the language design. An example: a type inference algorithm might be easy to implement, but it might behave unpredictably – e.g. if you change (e1,e2) to (e2,e1) the type inference fails – that is, it might be hard to specify in a programmer-accessible way. Actually linear types could be like this. The paper explicitly does not handle type inference; and neither does the proposal. I’d be surprised if we couldn’t come up with an inference algorithm we all considered acceptable in language-design terms – not just in implementation terms – but still, it’s something we won’t know for a while. I’m only saying that at checkpoint [2] the criteria are not just code/implementation quality and complexity; it also implicitly includes a review of the judgement made at checkpoint [1], in case the “slow accretion” has happened. I don’t think there’s any disagreement here. No one wants a feature to end up in GHC that, in retrospect, we can see is mis-designed! We have to balance that with giving contributors confidence, and enough certainty to invest their most precious resource (their own time) in GHC. Nevertheless, we do *not* need a priori and inherently imprecise evaluation of whether a proposal is ”big” or complex. In fact, our process (the whole pipeline above) is adaptive Yes – I’m not particularly seeking an a-priori evaluation of size (although, thinking aloud, I did speculate about such a thing). But being adaptive is important. A fly and an elephant are creatures on a continuous scale of creature sizes. There is no point at which we can say “this creature is Big and the next smallest one is NotBig”. And yet in the end elephants and flies really do need rather different treatment. Simon From: Manuel M T Chakravarty [mailto:chak at justtesting.org] Sent: 15 November 2017 02:26 To: Simon Peyton Jones Cc: Richard Eisenberg ; ghc-steering-committee at haskell.org Subject: Re: [ghc-steering-committee] Our process and BIG ideas Simon, I think, the suggestion to add a formal point about detailing the effect of an extension on Core is fabulous! We should absolutely do that. It seems the sticky point is your first, the slow accretion of hidden costs. It totally agree that this is the most tricky scenario. However, I am not so sure that there is no moment, where that costs are checked. There is none if we look at this committee in isolation. However, there is one if we look at the entire process of getting an extension into GHC (and I think, this is key to making this all work elegantly). Here is the pipeline: Proposal | v [1] (GHC Steering Committee) | Pull Request/Differential | v [2] (Code reviewers) | Development version | v [3] (Release Manager) | v Released feature For anything to get into a stable release, there are three checks [1], [2] & [3] that need to be passed. What I propose is that failure to pass one of the checks doesn’t just prevent you from getting further, but that it may throw you back to an earlier stage. In the proposal, we do ask about the implementation costs and costs of feature interaction etc. I like to suggest that if a code contribution backed by a proposal is submitted for consideration for merging, the code reviewers check that the code contribution actually meets the promises made in the proposal about, for example, implementation costs. If these promises are not met, there are two possibilities: (a) The implementation is just not very good. In that case, the contributors can try to improve their code and try again. (b) The implementation is good, but the implementation turned out to be more costly than originally anticipated. In this case, code review will ask the contributor to revise their proposal, go back to the GHC Steering Committee, and get the revision approved. Now, this is the moment where the committee is asked to review the proposal in the light of the newly gained experience. For example, following your suggestion about explicitly asking proposal authors to detail the impact of an extension on Core. A proposal may claim to not have to change Core at all. Then, it turns out the implementation actually does change Core, maybe just in a small way. Nevertheless, this clearly signals to code review that the proposal was inaccurate. Hence, the proposal has to go back to the GHC Steering Committee and be re-approved. As another example, assume that we have got a big complex proposal and the authors write that they are —at this stage— unsure about the exact impact on Core. In this case, just as with the or-patterns and GADTs, we may review the proposal, but make final approval contingent on understanding the actual impact on Core. In this manner, the committee gets to re-check proposals, where substantial new experience was gained during the implementation that altered trade offs of implementation costs, feature interaction etc. Nevertheless, we do *not* need a priori and inherently imprecise evaluation of whether a proposal is ”big” or complex. In fact, our process (the whole pipeline above) is adaptive. The less accurate a proposal turns out to be (due to complexity or other factors), the more often it’ll be thrown back and re-evaluated. And maybe the fact that a proposal is thrown back multiple times will make us weary of it and cause us to eventually reject it. Manuel Simon Peyton Jones >: I’m ok with what Manuel says, especially the bit about being more explicit about the implicit conditionality. But I would add * Acceptance is always a balance of judgement. Is the extra language and implementation complexity justified by the benefits to the programmer? For “big” features, that balance may change as we learn more about it. Manuel takes outright unsoundness as an example, and it is a comforting one because it’s so clear-cut. But in reality I think that it’s more likely that there’ll be a slow accretion of hidden costs that slowly become apparent. Then it might seem more capricious if the committee’s judgement changed; and in any case there’d be no moment at which the committee was asked to review the proposal in the light of experience. * I think we could address some of this by making the conditionality in acceptance more explicit, just as Manuel says. But in specific terms, not just in general ones. For example, for or-patterns I think we are edging towards “accept, provided we can resolve the issues around GADTs etc”. For a “bigger” proposal we might have a longer list of things we regarded as danger spots. * I suggest that we add to our criteria what effect (if any) the proposal has on Core. You may see Core as merely an implementation mechanism, but I regard it as a solid sanity check. We simply do not have a formal specification for all of Haskell. It’s too big, and if we insisted on that we ‘d never do anything. But we DO have a formal spec for Core. It is small enough to be intellectually tractable. And, for better or worse, GHC is one of the very few production compilers in the world (I actually do now know of any others) that maintain a statically typed IR right through optimisation up to code generation. Most proposals don’t change Core one whit. But for those that do, I think it would be reasonable to ask for a pretty solid spec of what changes are proposed. That would reassure us that the proposal is in fact sound. All the rest is syntactic sugar, as it were. Simon From: Manuel M T Chakravarty [mailto:chak at justtesting.org] Sent: 14 November 2017 01:10 To: Simon Peyton Jones > Cc: Richard Eisenberg >; ghc-steering-committee at haskell.org Subject: Re: [ghc-steering-committee] Our process and BIG ideas All approval is conditional ~~~~~~~~~~~~~~~~~~~~ I get the feeling that this discussion is actually really about, > What does approval mean? Currently, the ghc-proposals' README states, Acceptance of the proposal implies that the implementation will be accepted into GHC provided it is well-engineered, well-documented, and does not complicate the code-base too much. So, obviously and explicitly all acceptance of proposals by this committee is conditional (there is no unconditional approval). Everything is conditional on a good implementation. However, I would argue that —in actual fact— there are some conditions that we have never made explicit as well, and those implicit conditions are at the core of the current discussion. For example, proposals like TypeInType, linear types, or dependent types may well turn out to be impossible to implement *without complicating the code-base too much* (e.g., because they need to change Core in ways that are too intrusive). In other words, if the required engineering constraints are impossible to meet for a proposal, then, despite it originally being accepted, we wouldn’t allow it into a shipping compiler. I will go further and argue that there are conditions that are not mentioned at all. For example, let’s assume I make a convincing argument for a type extension and I have a conference paper and a proof of progress and preservation, and the committee accepts my proposal. If, during implementation, I or somebody else find that my proof is actually faulty and the system is unsound, would we allow it into the compiler only because we accepted the proposal? Of course not! Hence, all accepted proposals are also conditional on that the properties and assumptions stated in the proposal are actually correct. If a proposal claims that an extension is sound, it must be sound. If it states that it doesn’t conflict with other type extension, it may not conflict. If it argues, the implementation will be efficient, it must be efficient, and so on. If anything turns out to be wrong, the approval, which was issued under these assumptions, is void. (Think of it as a contract that is voided once any of the clauses is violated.) So, I hope we can agree that all approval is conditional. What we need to do is to specify the conditions that we implicitly assign beyond the engineering focused condition that is currently in the README. (Having conditions is fine, but to be fair to proposal authors, IMHO we need to be explicit about them.) Size doesn’t matter ~~~~~~~~~~~~~~~ I like to argue that the size of a proposal is much less important than we might think. Fairly small changes can easily turn into a pit of vipers. For example, take generalised new type deriving. It was such a small simple change and easy to do with System FC’s equality constraints. If we had had GHC proposals at the time, this would have been a small proposal relative to the fancy type family additions and GADTs going on at the time. Nevertheless, I’d argue, generalised newtype deriving was probably the biggest type soundness nightmare GHC ever had. (How many papers did it take to fix it…kind of?) Whether a proposal is long or short, whether it involves complex types, or whether it is just syntax (that may always turn out to be really hard to implement with LALR(1)), I think, we want the same rules and the same conditions attached to approval of the proposal. * There needs to a well-engineered implementation. * It shouldn’t complicate the codebase too much. * It must not have unexpected interactions with other language features. * It must not unduly affect the performance of the compiler (neither of compilation nor of the generated code). * It must not turn out to be unsound. * It must not turn out to lead to impossible to understand error messages. * What else? All these conditions must be met by *all* proposals, large or small. Every approval is always conditional on all of these conditions. What if a condition is violated ~~~~~~~~~~~~~~~~~~~~~~ That depends on whether the problem can be fixed and what kind of fix is needed. Anything that is ”just” a matter of code quality is a matter for the code reviewers to hold back until it is good enough. Anything destabilising the compiler or turning out to affect performance too much is up to the release manager to prevent going into an actual release. These issues are not a concern of this committee. However, if a conceptual problem is found, a system is unsound, or generally any of the assumptions or statements in the proposal *on which approval was based* turns out to be wrong, the proposal needs to be changed. Once it is changed, it needs to be approved again. If no acceptable change can be found, the proposal is out. Summary ~~~~~~~ I propose to make the conditions (that always existed) explicit, check them while a proposal gets refined and potential issues discovered during implementation, and bounce any (significant) changes that need to be made back to the committee. In this way, I hope, we can address the concerns voiced by Simon and Richard, while being completely transparent to proposal authors. Moreover, we don’t need any a priori judgement about whether a proposal is small or large (and where exactly is that boundary). Instead, naturally, anything that leads to issues will be sent back to the committee, which allows for iteration exactly where this is necessary. Cheers, Manuel Simon Peyton Jones >: | However, I'm leery of unconditional approval of something as large as the | linear types proposal. If "unconditional approval" means " we agree to include this feature in GHC, regardless of the consequences", then I guess everyone would agree with Richard. It's not just the implementation consequences either: we have to think about the interaction of a big new feature with all the other aspects of the surface language, and that is really hard to do in advance. For little proposals (like commas in export lists) we can be pretty confident that we aren't going to get any major surprises. For big ones like this, our confidence is much lower. But we must think of it from the contributors' point of view too. Contributors to GHC want to see a transparent and somewhat predictable pipeline of steps that successively make it more and more likely that a proposal will end up in mainstream GHC. For big proposals maybe we need more steps. E.g. 1. Philosophically, we like the direction of travel. If there are no surprises, we'd like to have this in the language. 2. Details. Now there are lot of specifics. Interactions with other features of Haskell. If there are going to be changes in Core, a precise specification of those changes would be helpful. (I know that Core is an internal matter, but it's an outstandingly good sanity-check.) 3. Implementation. Now we have an implementation. 4. Merge into HEAD We have previously conflated (1) and (2) and that seems fine for a small proposal, but for a big one like this we might want to split the steps, to offer authors the confidence to invest in (2). Actually (2) and (3) are likely to be symbiotic, I think. Does that make sense? Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces at haskell.org] On Behalf Of Richard Eisenberg | Sent: 13 November 2017 03:25 | To: Manuel M T Chakravarty > | Cc: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] Our process and BIG ideas | | I fully agree that proposals for large new features can reference an | accompanying paper. | | However, I'm leery of unconditional approval of something as large as the | linear types proposal. GHC is a very large, complex system, and no one can | anticipate all the interactions that a proposal may have with existing | features. It's quite possible that something which seems like a good idea | has a disastrous interaction with some other part of the compiler/language | definition. | | Instead, I would favor a conditional approval that would turn to rejection | only if further experience (gained through a [partial] implementation) | reveals a theoretical sticking point. I use "theoretical" here to mean that | the rejection wouldn't be based on poor code quality or an implementation | challenge, per se, but by running into a scenario where we are unable to | specify the correct behavior of the system. | | In truth, even an approval that we described as unconditional would really | be as in the paragraph above -- we simply can't do better. So I guess I'm | favoring calling such an approval as conditional, just to be clear to | proposers what we mean. | | Richard | | > On Nov 12, 2017, at 10:07 PM, Manuel M T Chakravarty | > wrote: | > | > In the light of the linear types proposal PR, SimonPJ’s comment | > | > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% | 2Fghc-proposals%2Fghc-proposals%2Fpull%2F91%23issuecomment- | 343457821&data=02%7C01%7Csimonpj%40microsoft.com%7C76a50b24b6dc436c9c4808d52 | a463534%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636461403387929271&sdat | a=%2FGtP16v%2BiJEDwkd0TpX6yKpXS0bZaOh1HWDCEsPTiDg%3D&reserved=0 | > | > and some uncertainty about the proposal process that has been communicated | to me via a side channel, it might be worthwhile clarifying our expectations | for large complex proposals. (I know, we basically punted on these questions | in our initial discussion on the process with the intention to revisit after | we gained some experience. It seems this time has come.) | > | > Firstly, we usually require proposals to be self-contained. This makes a | lot of sense for small to medium-sized proposals to limit the time needed by | the committee to hunt down all the required information. However, in a case, | such as the linear types work, where there is a highly polished text in the | form of a research paper (or similar), it seems reasonable to refer to that | existing work — not only because type rules are a lot nicer to read when | rendered by LaTeX instead of Markdown. | > | > Concretely, I’d like us to give some guidance wrt to this issue to | proposal authors and document that at | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% | 2Fghc-proposals%2Fghc-proposals%23ghc- | proposals&data=02%7C01%7Csimonpj%40microsoft.com%7C76a50b24b6dc436c9c4808d52 | a463534%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636461403387929271&sdat | a=Z8x%2FqlkWGH4dt43vQYpU9yP7YGGBZ4NR920%2FBS6EMA4%3D&reserved=0 | > | > Secondly, Simon, you seem to suggest that a large proposal like this | wouldn’t be either accepted or rejected, but put into a kind a limbo state | of further evaluation as seen fit. I agree that instead of outright | rejection of a proposal that we consider flawed but not hopeless, we might | request further elaboration and resubmission as we have done in the past. | However, if a proposal passes muster, I think, we should accept it | unconditionally, even if it is a large change. (If, say, at the end, the | implementation is not up to scratch, then it is up to the code reviewers to | reject the patches, but I don’t think, it is this committee’s job anymore.) | > | > In any case, I think, it is important make the process as clear as | possible to authors, so they know what they are in for. | > | > What do you all think? | > | > Cheers, | > Manuel | > | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee at haskell.org | > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Nov 21 21:24:06 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 21 Nov 2017 16:24:06 -0500 Subject: [ghc-steering-committee] Please review: add incomplete-uni-patterns and incomplete-record-updates to -Wall, Shepherd: Simon Marlow Message-ID: <1511299446.1801.2.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: The question of whether the meaning of -Wall out to include incomplete- uni-patterns and incomplete-record-updates was brought before the committee. https://github.com/ghc-proposals/ghc-proposals/pull/71 I propose Simon Marlow as the Shepherd. Simon, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Mon Nov 27 14:46:46 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 27 Nov 2017 09:46:46 -0500 Subject: [ghc-steering-committee] Proposal: BlockArguments (Shepherd: Joachim) Message-ID: <1511794006.1011.18.camel@joachim-breitner.de> Dear committee, the BlockArguments (former ArgumentDo) proposal was brought before us: https://github.com/ghc-proposals/ghc-proposals/pull/90 I’ll shepherd this myself. The idea is to not require parenthesis around block syntax elements such as lambda expressions, let bindings, if-then-else, case-of and (in particular) do expressions. The change to the grammar to enable that is actually a simplificiation (it removes one non-terminal, lexp). Variants proposed are: * do this only for `do` in argument position, or * do it for all blocks, but only in function argument positions. I am fond of this proposal, because it allows code with less parenthesis to be written. If Haskell was written from ground up, I believe there would be little opposition to this setup, and maybe we would not have had to hack higher-rank support into ($), as the idiom `runST $ do …` would just be `runST do …`. Another argument in favor of it is the mentioned simplificiation of the grammar rules. I am aware that reading the parenthesis-free code feels strange to many, but I not overly worried about that: Every change feels strange, and in this case, only code that is otherwise illegal is affected. Akio has indicated that he is willing to work on the implementation. Therefore, I suggest that we accept this proposal. Please discuss (or voice you silent agreement). Regards, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Mon Nov 27 14:53:39 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 27 Nov 2017 09:53:39 -0500 Subject: [ghc-steering-committee] What do we need from the linear-types proposal? Message-ID: <1511794419.1011.22.camel@joachim-breitner.de> Dear committee, Mathieu Boespflug asks on https://github.com/ghc-proposals/ghc-proposals/pull/91#issuecomment-347123204 > Could the Committee define the items it expects before it can make a > determination about this proposal? We've heard in this thread members > of the Committee ask for a fleshed out linear base, more examples > than are already in the proposal and in the paper, and also full code > from other users at large. I can certainly understand where they are > coming from. But at the same time, I am concerned about scope creep. > Defining where the goal posts are from now would certainly help. and I am not sure what to reply here… but “we’ll know that once we made a determination” is probably not helpful. Does anyone here feel like he could define the requirements that are necessary to allow us to consider the proposal properly? Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Mon Nov 27 14:58:10 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 27 Nov 2017 14:58:10 +0000 Subject: [ghc-steering-committee] What do we need from the linear-types proposal? In-Reply-To: <1511794419.1011.22.camel@joachim-breitner.de> References: <1511794419.1011.22.camel@joachim-breitner.de> Message-ID: The main thing I'd add, which applies to all proposals is this: * If a proposal requires a change to Core, that change should be described rather precisely. The justification for this is in my comments on the linear-types thread. Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces at haskell.org] On Behalf Of Joachim Breitner | Sent: 27 November 2017 14:54 | To: ghc-steering-committee at haskell.org | Subject: [ghc-steering-committee] What do we need from the linear-types | proposal? | | Dear committee, | | Mathieu Boespflug asks on | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fghc-proposals%2Fghc-proposals%2Fpull%2F91%23issuecomment- | 347123204&data=02%7C01%7Csimonpj%40microsoft.com%7C44b56cc9019549c8dc5f08 | d535a6ad85%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63647391234812744 | 2&sdata=LqVQJviHF8Wxbc3QHiPWe2C2pK%2FTXX12GbmxPLJEOi0%3D&reserved=0 | | > Could the Committee define the items it expects before it can make a | > determination about this proposal? We've heard in this thread members | > of the Committee ask for a fleshed out linear base, more examples than | > are already in the proposal and in the paper, and also full code from | > other users at large. I can certainly understand where they are coming | > from. But at the same time, I am concerned about scope creep. | > Defining where the goal posts are from now would certainly help. | | and I am not sure what to reply here… but “we’ll know that once we made a | determination” is probably not helpful. | | Does anyone here feel like he could define the requirements that are | necessary to allow us to consider the proposal properly? | | Thanks, | Joachim | | | -- | Joachim Breitner | mail at joachim-breitner.de | | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach | im- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C44b56cc9019549c8d | c5f08d535a6ad85%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636473912348 | 127442&sdata=zDtUrSDruKvFJWEKfJHXeISRDM21q9juzyBdyjLYUzs%3D&reserved=0 From simonpj at microsoft.com Mon Nov 27 15:32:49 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 27 Nov 2017 15:32:49 +0000 Subject: [ghc-steering-committee] Proposal: BlockArguments (Shepherd: Joachim) In-Reply-To: <1511794006.1011.18.camel@joachim-breitner.de> References: <1511794006.1011.18.camel@joachim-breitner.de> Message-ID: I'm neutral on this. Clearly it's purely a UI issue; there is little impact on the compiler. I'm a bit bothered not so much by knowing were one of these block-arguments /begin/ as knowing where it /ends/. But I'm not opposing. Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces at haskell.org] On Behalf Of Joachim Breitner | Sent: 27 November 2017 14:47 | To: ghc-steering-committee at haskell.org | Subject: [ghc-steering-committee] Proposal: BlockArguments (Shepherd: | Joachim) | | Dear committee, | | the BlockArguments (former ArgumentDo) proposal was brought before us: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fghc-proposals%2Fghc- | proposals%2Fpull%2F90&data=02%7C01%7Csimonpj%40microsoft.com%7C5002e529d3 | d145d0cd3908d535a5b7ef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63647 | 3908229182766&sdata=dwqEwkLl3ykQjs2PKWJzaV7z2UegZizNLIsf%2F%2FTD2CI%3D&re | served=0 | | I’ll shepherd this myself. | | The idea is to not require parenthesis around block syntax elements such | as lambda expressions, let bindings, if-then-else, case-of and (in | particular) do expressions. The change to the grammar to enable that is | actually a simplificiation (it removes one non-terminal, lexp). | | Variants proposed are: | * do this only for `do` in argument position, or | * do it for all blocks, but only in function argument positions. | | | I am fond of this proposal, because it allows code with less parenthesis | to be written. If Haskell was written from ground up, I believe there | would be little opposition to this setup, and maybe we would not have had | to hack higher-rank support into ($), as the idiom `runST $ do …` would | just be `runST do …`. | | Another argument in favor of it is the mentioned simplificiation of the | grammar rules. | | I am aware that reading the parenthesis-free code feels strange to many, | but I not overly worried about that: Every change feels strange, and in | this case, only code that is otherwise illegal is affected. | | Akio has indicated that he is willing to work on the implementation. | | | Therefore, I suggest that we accept this proposal. | | | Please discuss (or voice you silent agreement). | | Regards, | Joachim | | -- | Joachim Breitner | mail at joachim-breitner.de | | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach | im- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C5002e529d3d145d0c | d3908d535a5b7ef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636473908229 | 182766&sdata=xChzRShUBaqVnsFx%2BlpgjJT8zzK2qKcwUDmr%2FXPzMGM%3D&reserved= | 0 From rae at cs.brynmawr.edu Mon Nov 27 21:36:26 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 27 Nov 2017 16:36:26 -0500 Subject: [ghc-steering-committee] Proposal: BlockArguments (Shepherd: Joachim) In-Reply-To: References: <1511794006.1011.18.camel@joachim-breitner.de> Message-ID: <5511F870-86B9-4E7A-B4CF-C6FC45793DF3@cs.brynmawr.edu> > On Nov 27, 2017, at 10:32 AM, Simon Peyton Jones wrote: > > I'm neutral on this. Clearly it's purely a UI issue; there is little impact on the compiler. > > I'm a bit bothered not so much by knowing were one of these block-arguments /begin/ as knowing where it /ends/. But I'm not opposing. The "ends" problem applies only to constructs that do not introduce layout (or, rather, do not end with a layout close-brace). Those that introduce layout end at the close-brace -- simple. Thus, the ending of `do`, `case`, `\case`, and `if|` (multi-way if) are fairly apparent, while `\`, `if` and `let` are not. Perhaps we could treat these separately, if end-detection is so bothersome. Actually, though, I support the proposal in its current form, including support for the hard-to-end constructs. Richard > > Simon > > | -----Original Message----- > | From: ghc-steering-committee [mailto:ghc-steering-committee- > | bounces at haskell.org] On Behalf Of Joachim Breitner > | Sent: 27 November 2017 14:47 > | To: ghc-steering-committee at haskell.org > | Subject: [ghc-steering-committee] Proposal: BlockArguments (Shepherd: > | Joachim) > | > | Dear committee, > | > | the BlockArguments (former ArgumentDo) proposal was brought before us: > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c > | om%2Fghc-proposals%2Fghc- > | proposals%2Fpull%2F90&data=02%7C01%7Csimonpj%40microsoft.com%7C5002e529d3 > | d145d0cd3908d535a5b7ef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63647 > | 3908229182766&sdata=dwqEwkLl3ykQjs2PKWJzaV7z2UegZizNLIsf%2F%2FTD2CI%3D&re > | served=0 > | > | I’ll shepherd this myself. > | > | The idea is to not require parenthesis around block syntax elements such > | as lambda expressions, let bindings, if-then-else, case-of and (in > | particular) do expressions. The change to the grammar to enable that is > | actually a simplificiation (it removes one non-terminal, lexp). > | > | Variants proposed are: > | * do this only for `do` in argument position, or > | * do it for all blocks, but only in function argument positions. > | > | > | I am fond of this proposal, because it allows code with less parenthesis > | to be written. If Haskell was written from ground up, I believe there > | would be little opposition to this setup, and maybe we would not have had > | to hack higher-rank support into ($), as the idiom `runST $ do …` would > | just be `runST do …`. > | > | Another argument in favor of it is the mentioned simplificiation of the > | grammar rules. > | > | I am aware that reading the parenthesis-free code feels strange to many, > | but I not overly worried about that: Every change feels strange, and in > | this case, only code that is otherwise illegal is affected. > | > | Akio has indicated that he is willing to work on the implementation. > | > | > | Therefore, I suggest that we accept this proposal. > | > | > | Please discuss (or voice you silent agreement). > | > | Regards, > | Joachim > | > | -- > | Joachim Breitner > | mail at joachim-breitner.de > | > | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach > | im- > | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C5002e529d3d145d0c > | d3908d535a5b7ef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636473908229 > | 182766&sdata=xChzRShUBaqVnsFx%2BlpgjJT8zzK2qKcwUDmr%2FXPzMGM%3D&reserved= > | 0 > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From rae at cs.brynmawr.edu Mon Nov 27 22:04:28 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 27 Nov 2017 17:04:28 -0500 Subject: [ghc-steering-committee] What do we need from the linear-types proposal? In-Reply-To: References: <1511794419.1011.22.camel@joachim-breitner.de> Message-ID: <85EF2AF9-95A9-4517-989A-1C1ECECF0378@cs.brynmawr.edu> > On Nov 27, 2017, at 9:58 AM, Simon Peyton Jones wrote: > > * If a proposal requires a change to Core, that change should be > described rather precisely. In Greek or in Haskell? Less tersely: does a formalization in a paper suffice? Or should the proposal write out the new Haskell definition? These are closely related, but not the same. (For example, formalizations don't include the AppTy/TyConApp/FunTy distinction that is important for performance.) My own view is that Greek is enough. Richard From iavor.diatchki at gmail.com Tue Nov 28 01:23:18 2017 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 28 Nov 2017 01:23:18 +0000 Subject: [ghc-steering-committee] Proposal: BlockArguments (Shepherd: Joachim) In-Reply-To: <5511F870-86B9-4E7A-B4CF-C6FC45793DF3@cs.brynmawr.edu> References: <1511794006.1011.18.camel@joachim-breitner.de> <5511F870-86B9-4E7A-B4CF-C6FC45793DF3@cs.brynmawr.edu> Message-ID: Hello, I also support this proposal, and think if we do this we should do it for all forms, not just some. -Iavor On Mon, Nov 27, 2017 at 1:36 PM Richard Eisenberg wrote: > > > On Nov 27, 2017, at 10:32 AM, Simon Peyton Jones > wrote: > > > > I'm neutral on this. Clearly it's purely a UI issue; there is little > impact on the compiler. > > > > I'm a bit bothered not so much by knowing were one of these > block-arguments /begin/ as knowing where it /ends/. But I'm not opposing. > > The "ends" problem applies only to constructs that do not introduce layout > (or, rather, do not end with a layout close-brace). Those that introduce > layout end at the close-brace -- simple. Thus, the ending of `do`, `case`, > `\case`, and `if|` (multi-way if) are fairly apparent, while `\`, `if` and > `let` are not. Perhaps we could treat these separately, if end-detection is > so bothersome. > > Actually, though, I support the proposal in its current form, including > support for the hard-to-end constructs. > > Richard > > > > > Simon > > > > | -----Original Message----- > > | From: ghc-steering-committee [mailto:ghc-steering-committee- > > | bounces at haskell.org] On Behalf Of Joachim Breitner > > | Sent: 27 November 2017 14:47 > > | To: ghc-steering-committee at haskell.org > > | Subject: [ghc-steering-committee] Proposal: BlockArguments (Shepherd: > > | Joachim) > > | > > | Dear committee, > > | > > | the BlockArguments (former ArgumentDo) proposal was brought before us: > > | > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c > > | om%2Fghc-proposals%2Fghc- > > | proposals%2Fpull%2F90&data=02%7C01%7Csimonpj%40microsoft.com > %7C5002e529d3 > > | > d145d0cd3908d535a5b7ef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63647 > > | > 3908229182766&sdata=dwqEwkLl3ykQjs2PKWJzaV7z2UegZizNLIsf%2F%2FTD2CI%3D&re > > | served=0 > > | > > | I’ll shepherd this myself. > > | > > | The idea is to not require parenthesis around block syntax elements > such > > | as lambda expressions, let bindings, if-then-else, case-of and (in > > | particular) do expressions. The change to the grammar to enable that is > > | actually a simplificiation (it removes one non-terminal, lexp). > > | > > | Variants proposed are: > > | * do this only for `do` in argument position, or > > | * do it for all blocks, but only in function argument positions. > > | > > | > > | I am fond of this proposal, because it allows code with less > parenthesis > > | to be written. If Haskell was written from ground up, I believe there > > | would be little opposition to this setup, and maybe we would not have > had > > | to hack higher-rank support into ($), as the idiom `runST $ do …` would > > | just be `runST do …`. > > | > > | Another argument in favor of it is the mentioned simplificiation of the > > | grammar rules. > > | > > | I am aware that reading the parenthesis-free code feels strange to > many, > > | but I not overly worried about that: Every change feels strange, and in > > | this case, only code that is otherwise illegal is affected. > > | > > | Akio has indicated that he is willing to work on the implementation. > > | > > | > > | Therefore, I suggest that we accept this proposal. > > | > > | > > | Please discuss (or voice you silent agreement). > > | > > | Regards, > > | Joachim > > | > > | -- > > | Joachim Breitner > > | mail at joachim-breitner.de > > | > > | > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach > > | im- > > | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com > %7C5002e529d3d145d0c > > | > d3908d535a5b7ef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636473908229 > > | > 182766&sdata=xChzRShUBaqVnsFx%2BlpgjJT8zzK2qKcwUDmr%2FXPzMGM%3D&reserved= > > | 0 > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Tue Nov 28 02:15:36 2017 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 28 Nov 2017 02:15:36 +0000 Subject: [ghc-steering-committee] What do we need from the linear-types proposal? In-Reply-To: <85EF2AF9-95A9-4517-989A-1C1ECECF0378@cs.brynmawr.edu> References: <1511794419.1011.22.camel@joachim-breitner.de> <85EF2AF9-95A9-4517-989A-1C1ECECF0378@cs.brynmawr.edu> Message-ID: Hello, Coming up with a concrete list of suggestions is hard, but here are a couple things that would make it easier for me to understand large proposals (e.g., like the linear types one): 1. It is good if large proposals are "modular", meaning that you can understand them (and perhaps implement them), one piece at a time. For example, adding certain features to the language may enable us to make library changes, but that sort of thing can be disused separately. 2. I think that it would be good if the proposal contains enough information to get a feeling for the core idea of the proposal, both how it might be used, and about how it might be implemented, without referring to external papers. One thing that works well for me is to see lots of examples which illustrate various aspects of the design. Generally, I find it much easier to understand and generalize from a set of examples, than a set of rules, especially if the rules are not accompanied by an explanation of the reasons for choosing them. -Iavor On Mon, Nov 27, 2017 at 2:04 PM Richard Eisenberg wrote: > > > On Nov 27, 2017, at 9:58 AM, Simon Peyton Jones > wrote: > > > > * If a proposal requires a change to Core, that change should be > > described rather precisely. > > In Greek or in Haskell? Less tersely: does a formalization in a paper > suffice? Or should the proposal write out the new Haskell definition? These > are closely related, but not the same. (For example, formalizations don't > include the AppTy/TyConApp/FunTy distinction that is important for > performance.) > > My own view is that Greek is enough. > > Richard > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Nov 28 10:18:11 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 28 Nov 2017 10:18:11 +0000 Subject: [ghc-steering-committee] What do we need from the linear-types proposal? In-Reply-To: <85EF2AF9-95A9-4517-989A-1C1ECECF0378@cs.brynmawr.edu> References: <1511794419.1011.22.camel@joachim-breitner.de> <85EF2AF9-95A9-4517-989A-1C1ECECF0378@cs.brynmawr.edu> Message-ID: I agree -- Greek is enough providing it is complete enough to convince the reader that the transliteration will be routine. Simon | -----Original Message----- | From: Richard Eisenberg [mailto:rae at cs.brynmawr.edu] | Sent: 27 November 2017 22:04 | To: Simon Peyton Jones | Cc: Joachim Breitner ; ghc-steering- | committee at haskell.org | Subject: Re: [ghc-steering-committee] What do we need from the linear- | types proposal? | | | > On Nov 27, 2017, at 9:58 AM, Simon Peyton Jones | wrote: | > | > * If a proposal requires a change to Core, that change should be | > described rather precisely. | | In Greek or in Haskell? Less tersely: does a formalization in a paper | suffice? Or should the proposal write out the new Haskell definition? | These are closely related, but not the same. (For example, | formalizations don't include the AppTy/TyConApp/FunTy distinction that | is important for performance.) | | My own view is that Greek is enough. | | Richard From simonpj at microsoft.com Tue Nov 28 10:25:04 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 28 Nov 2017 10:25:04 +0000 Subject: [ghc-steering-committee] What do we need from the linear-types proposal? In-Reply-To: References: <1511794419.1011.22.camel@joachim-breitner.de> <85EF2AF9-95A9-4517-989A-1C1ECECF0378@cs.brynmawr.edu> Message-ID: it would be good if the proposal contains enough information to get a feeling for the core idea of the proposal, both how it might be used, and about how it might be implemented, without referring to external papers. I don’t really agree with this. Papers tend to be the result of a great deal of focused attention and multiple iterations. It’s hard (and indeed wasteful) to duplicate that effort in a proposal. Better just to point to it. (On the rare occasions where there is a paper that squarely addresses the topic of the proposal.) But yes, more examples (not duplicate examples) are always good. Simon From: Iavor Diatchki [mailto:iavor.diatchki at gmail.com] Sent: 28 November 2017 02:16 To: Richard Eisenberg Cc: Simon Peyton Jones ; ghc-steering-committee at haskell.org; Joachim Breitner Subject: Re: [ghc-steering-committee] What do we need from the linear-types proposal? Hello, Coming up with a concrete list of suggestions is hard, but here are a couple things that would make it easier for me to understand large proposals (e.g., like the linear types one): 1. It is good if large proposals are "modular", meaning that you can understand them (and perhaps implement them), one piece at a time. For example, adding certain features to the language may enable us to make library changes, but that sort of thing can be disused separately. 2. I think that it would be good if the proposal contains enough information to get a feeling for the core idea of the proposal, both how it might be used, and about how it might be implemented, without referring to external papers. One thing that works well for me is to see lots of examples which illustrate various aspects of the design. Generally, I find it much easier to understand and generalize from a set of examples, than a set of rules, especially if the rules are not accompanied by an explanation of the reasons for choosing them. -Iavor On Mon, Nov 27, 2017 at 2:04 PM Richard Eisenberg > wrote: > On Nov 27, 2017, at 9:58 AM, Simon Peyton Jones > wrote: > > * If a proposal requires a change to Core, that change should be > described rather precisely. In Greek or in Haskell? Less tersely: does a formalization in a paper suffice? Or should the proposal write out the new Haskell definition? These are closely related, but not the same. (For example, formalizations don't include the AppTy/TyConApp/FunTy distinction that is important for performance.) My own view is that Greek is enough. Richard _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Tue Nov 28 18:18:11 2017 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 28 Nov 2017 18:18:11 +0000 Subject: [ghc-steering-committee] What do we need from the linear-types proposal? In-Reply-To: References: <1511794419.1011.22.camel@joachim-breitner.de> <85EF2AF9-95A9-4517-989A-1C1ECECF0378@cs.brynmawr.edu> Message-ID: I suspect we are in agreement here. What I was trying to capture is the fact that in my experience papers tend to contain both more and less than what I'd expect to find in a GHC proposal. They contain more, in that they may address important issues such as proofs of soundness, or other important properties, much more extended motivation, comparisons to other research, etc.. I don't think these belong in a proposal, but I think it is a big plus for a proposal to refer to a published papers addressing such issues. I think, however, sometimes (often?) papers also tend to aim at a fairly general explanation of concepts, that is not specific to a particular language. I think that GHC proposal should contain this extra detail, and be aimed at how the feature would be added to Haskell in particular (and even more concretely, to GHC). This involves discussing concrete syntax, interactions with other language features, and a lot of examples, so that a Haskell user can get a feel of what the new feature might feel like. Overall, I am a bit weary of publishing a list of "requirements" for a proposal, mostly because anything we publish could probably be interpreted in different ways, and I think---for me---it is much more important that we collectively think the proposal is a good idea, than there being a check-list that has been completely checked-off. -Iavor On Tue, Nov 28, 2017 at 2:25 AM Simon Peyton Jones wrote: > it would be good if the proposal contains enough information to get a > feeling for the core idea of the proposal, both how it might be used, and > about how it might be implemented, without referring to external papers. > > > > I don’t really agree with this. Papers tend to be the result of a great > deal of focused attention and multiple iterations. It’s hard (and indeed > wasteful) to duplicate that effort in a proposal. Better just to point to > it. (On the rare occasions where there is a paper that squarely addresses > the topic of the proposal.) > > > > But yes, more examples (not duplicate examples) are always good. > > > > Simon > > > > *From:* Iavor Diatchki [mailto:iavor.diatchki at gmail.com] > *Sent:* 28 November 2017 02:16 > *To:* Richard Eisenberg > *Cc:* Simon Peyton Jones ; > ghc-steering-committee at haskell.org; Joachim Breitner < > mail at joachim-breitner.de> > *Subject:* Re: [ghc-steering-committee] What do we need from the > linear-types proposal? > > > > Hello, > > > > Coming up with a concrete list of suggestions is hard, but here are a > couple things that would make it easier for me to understand large > proposals (e.g., like the linear types one): > > > > 1. It is good if large proposals are "modular", meaning that you can > understand them (and perhaps implement them), one piece at a time. For > example, adding certain features to the language may enable us to make > library changes, but that sort of thing can be disused separately. > > > > 2. I think that it would be good if the proposal contains enough > information to get a feeling for the core idea of the proposal, both how it > might be used, and about how it might be implemented, without referring to > external papers. One thing that works well for me is to see lots of > examples which illustrate various aspects of the design. Generally, I find > it much easier to understand and generalize from a set of examples, than a > set of rules, especially if the rules are not accompanied by an explanation > of the reasons for choosing them. > > > > -Iavor > > > > > > > > > > > > > > > > > > On Mon, Nov 27, 2017 at 2:04 PM Richard Eisenberg > wrote: > > > > On Nov 27, 2017, at 9:58 AM, Simon Peyton Jones > wrote: > > > > * If a proposal requires a change to Core, that change should be > > described rather precisely. > > In Greek or in Haskell? Less tersely: does a formalization in a paper > suffice? Or should the proposal write out the new Haskell definition? These > are closely related, but not the same. (For example, formalizations don't > include the AppTy/TyConApp/FunTy distinction that is important for > performance.) > > My own view is that Greek is enough. > > Richard > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Tue Nov 28 20:53:00 2017 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 28 Nov 2017 20:53:00 +0000 Subject: [ghc-steering-committee] Proposal: BlockArguments (Shepherd: Joachim) In-Reply-To: References: <1511794006.1011.18.camel@joachim-breitner.de> <5511F870-86B9-4E7A-B4CF-C6FC45793DF3@cs.brynmawr.edu> Message-ID: I'm also in favour. I vaguely recall this idea coming up at some point in the past - maybe the Haskell 98 discussion - so it would be interesting to know what the reason for omitting it was, but I have no idea how to search for it. My guess is it was just conservatism. Anyway, the only reason I can think of for rejection would be the potential to confuse people, but the impact of this is small. Let's ship it. Cheers Simon On 28 November 2017 at 01:23, Iavor Diatchki wrote: > Hello, > > I also support this proposal, and think if we do this we should do it for > all forms, not just some. > > -Iavor > > On Mon, Nov 27, 2017 at 1:36 PM Richard Eisenberg > wrote: > >> >> > On Nov 27, 2017, at 10:32 AM, Simon Peyton Jones >> wrote: >> > >> > I'm neutral on this. Clearly it's purely a UI issue; there is little >> impact on the compiler. >> > >> > I'm a bit bothered not so much by knowing were one of these >> block-arguments /begin/ as knowing where it /ends/. But I'm not opposing. >> >> The "ends" problem applies only to constructs that do not introduce >> layout (or, rather, do not end with a layout close-brace). Those that >> introduce layout end at the close-brace -- simple. Thus, the ending of >> `do`, `case`, `\case`, and `if|` (multi-way if) are fairly apparent, while >> `\`, `if` and `let` are not. Perhaps we could treat these separately, if >> end-detection is so bothersome. >> >> Actually, though, I support the proposal in its current form, including >> support for the hard-to-end constructs. >> >> Richard >> >> > >> > Simon >> > >> > | -----Original Message----- >> > | From: ghc-steering-committee [mailto:ghc-steering-committee- >> > | bounces at haskell.org] On Behalf Of Joachim Breitner >> > | Sent: 27 November 2017 14:47 >> > | To: ghc-steering-committee at haskell.org >> > | Subject: [ghc-steering-committee] Proposal: BlockArguments (Shepherd: >> > | Joachim) >> > | >> > | Dear committee, >> > | >> > | the BlockArguments (former ArgumentDo) proposal was brought before us: >> > | https://na01.safelinks.protection.outlook.com/?url= >> https%3A%2F%2Fgithub.c >> > | om%2Fghc-proposals%2Fghc- >> > | proposals%2Fpull%2F90&data=02%7C01%7Csimonpj%40microsoft.com >> %7C5002e529d3 >> > | d145d0cd3908d535a5b7ef%7C72f988bf86f141af91ab2d7cd011 >> db47%7C1%7C0%7C63647 >> > | 3908229182766&sdata=dwqEwkLl3ykQjs2PKWJzaV7z2UegZi >> zNLIsf%2F%2FTD2CI%3D&re >> > | served=0 >> > | >> > | I’ll shepherd this myself. >> > | >> > | The idea is to not require parenthesis around block syntax elements >> such >> > | as lambda expressions, let bindings, if-then-else, case-of and (in >> > | particular) do expressions. The change to the grammar to enable that >> is >> > | actually a simplificiation (it removes one non-terminal, lexp). >> > | >> > | Variants proposed are: >> > | * do this only for `do` in argument position, or >> > | * do it for all blocks, but only in function argument positions. >> > | >> > | >> > | I am fond of this proposal, because it allows code with less >> parenthesis >> > | to be written. If Haskell was written from ground up, I believe there >> > | would be little opposition to this setup, and maybe we would not have >> had >> > | to hack higher-rank support into ($), as the idiom `runST $ do …` >> would >> > | just be `runST do …`. >> > | >> > | Another argument in favor of it is the mentioned simplificiation of >> the >> > | grammar rules. >> > | >> > | I am aware that reading the parenthesis-free code feels strange to >> many, >> > | but I not overly worried about that: Every change feels strange, and >> in >> > | this case, only code that is otherwise illegal is affected. >> > | >> > | Akio has indicated that he is willing to work on the implementation. >> > | >> > | >> > | Therefore, I suggest that we accept this proposal. >> > | >> > | >> > | Please discuss (or voice you silent agreement). >> > | >> > | Regards, >> > | Joachim >> > | >> > | -- >> > | Joachim Breitner >> > | mail at joachim-breitner.de >> > | >> > | https://na01.safelinks.protection.outlook.com/?url= >> http%3A%2F%2Fwww.joach >> > | im- >> > | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com% >> 7C5002e529d3d145d0c >> > | d3908d535a5b7ef%7C72f988bf86f141af91ab2d7cd011 >> db47%7C1%7C0%7C636473908229 >> > | 182766&sdata=xChzRShUBaqVnsFx%2BlpgjJT8zzK2qKcwUDmr% >> 2FXPzMGM%3D&reserved= >> > | 0 >> > _______________________________________________ >> > ghc-steering-committee mailing list >> > ghc-steering-committee at haskell.org >> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc- >> steering-committee >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Nov 29 08:38:18 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 29 Nov 2017 08:38:18 +0000 Subject: [ghc-steering-committee] What do we need from the linear-types proposal? In-Reply-To: References: <1511794419.1011.22.camel@joachim-breitner.de> <85EF2AF9-95A9-4517-989A-1C1ECECF0378@cs.brynmawr.edu> Message-ID: Overall, I am a bit weary of publishing a list of "requirements" for a proposal, mostly because anything we publish could probably be interpreted in different ways, and I think---for me---it is much more important that we collectively think the proposal is a good idea, than there being a check-list that has been completely checked-off. Yes – but the more clarity we give the more likely we are to get good proposals, and to avoid misunderstandings. I think some effort is justified here. S From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org] On Behalf Of Iavor Diatchki Sent: 28 November 2017 18:18 To: ghc-steering-committee at haskell.org Subject: Re: [ghc-steering-committee] What do we need from the linear-types proposal? I suspect we are in agreement here. What I was trying to capture is the fact that in my experience papers tend to contain both more and less than what I'd expect to find in a GHC proposal. They contain more, in that they may address important issues such as proofs of soundness, or other important properties, much more extended motivation, comparisons to other research, etc.. I don't think these belong in a proposal, but I think it is a big plus for a proposal to refer to a published papers addressing such issues. I think, however, sometimes (often?) papers also tend to aim at a fairly general explanation of concepts, that is not specific to a particular language. I think that GHC proposal should contain this extra detail, and be aimed at how the feature would be added to Haskell in particular (and even more concretely, to GHC). This involves discussing concrete syntax, interactions with other language features, and a lot of examples, so that a Haskell user can get a feel of what the new feature might feel like. Overall, I am a bit weary of publishing a list of "requirements" for a proposal, mostly because anything we publish could probably be interpreted in different ways, and I think---for me---it is much more important that we collectively think the proposal is a good idea, than there being a check-list that has been completely checked-off. -Iavor On Tue, Nov 28, 2017 at 2:25 AM Simon Peyton Jones > wrote: it would be good if the proposal contains enough information to get a feeling for the core idea of the proposal, both how it might be used, and about how it might be implemented, without referring to external papers. I don’t really agree with this. Papers tend to be the result of a great deal of focused attention and multiple iterations. It’s hard (and indeed wasteful) to duplicate that effort in a proposal. Better just to point to it. (On the rare occasions where there is a paper that squarely addresses the topic of the proposal.) But yes, more examples (not duplicate examples) are always good. Simon From: Iavor Diatchki [mailto:iavor.diatchki at gmail.com] Sent: 28 November 2017 02:16 To: Richard Eisenberg > Cc: Simon Peyton Jones >; ghc-steering-committee at haskell.org; Joachim Breitner > Subject: Re: [ghc-steering-committee] What do we need from the linear-types proposal? Hello, Coming up with a concrete list of suggestions is hard, but here are a couple things that would make it easier for me to understand large proposals (e.g., like the linear types one): 1. It is good if large proposals are "modular", meaning that you can understand them (and perhaps implement them), one piece at a time. For example, adding certain features to the language may enable us to make library changes, but that sort of thing can be disused separately. 2. I think that it would be good if the proposal contains enough information to get a feeling for the core idea of the proposal, both how it might be used, and about how it might be implemented, without referring to external papers. One thing that works well for me is to see lots of examples which illustrate various aspects of the design. Generally, I find it much easier to understand and generalize from a set of examples, than a set of rules, especially if the rules are not accompanied by an explanation of the reasons for choosing them. -Iavor On Mon, Nov 27, 2017 at 2:04 PM Richard Eisenberg > wrote: > On Nov 27, 2017, at 9:58 AM, Simon Peyton Jones > wrote: > > * If a proposal requires a change to Core, that change should be > described rather precisely. In Greek or in Haskell? Less tersely: does a formalization in a paper suffice? Or should the proposal write out the new Haskell definition? These are closely related, but not the same. (For example, formalizations don't include the AppTy/TyConApp/FunTy distinction that is important for performance.) My own view is that Greek is enough. Richard _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: