From mail at joachim-breitner.de Thu Aug 3 15:03:05 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 03 Aug 2017 11:03:05 -0400 Subject: [ghc-steering-committee] Status Message-ID: <1501772585.27471.5.camel@joachim-breitner.de> Hi, since the last status update one new proposals has come up for deliberation, and no proposals were decided. Open at the moment are: NOUNPACK on function arguments https://github.com/ghc-proposals/ghc-proposals/pull/46 Shepherd: Simon Marlow Status: There was more discussion on GitHub, and @treeowl will have a look if the proposal text is reflecting all that discussion. Lazy unboxed tuples https://github.com/ghc-proposals/ghc-proposals/pull/35 Shepherd: Ryan Newton Status: Waiting for Ryan to make a recommendation. Explicit foralls proposal https://github.com/ghc-proposals/ghc-proposals/pull/55 Shepherd: Simon Peyton Jones Status: Waiting for Simon to make a recommendation. Mutable constructor fields https://github.com/ghc-proposals/ghc-proposals/pull/8 Shepherd: Ryan Newton Status: Waiting for Ryan to make a recommendation. 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 david.feuer at gmail.com Mon Aug 7 20:19:44 2017 From: david.feuer at gmail.com (David Feuer) Date: Mon, 7 Aug 2017 16:19:44 -0400 Subject: [ghc-steering-committee] Proposal format ambiguity Message-ID: The README and proposal template share an error. In the README: > Proposed Change Specification: > [...] > how the proposed change addresses the original problem (perhaps referring back to the example) > > Effect and Interactions. Detail how the proposed change addresses the original problem raised in the motivation. [...] In the template: > Proposed Change Specification > [...] > how the proposed change addresses the original problem > [...] > Effect and Interactions > > Detail how the proposed change addresses the original problem raised in the motivation. In each case, it is unclear whether the way the proposal addresses the original problem should appear in the proposed change specification section or the effects and interactions section. Minor side note: the title of the first section has a typo, "propsoal". David Feuer From mail at joachim-breitner.de Tue Aug 8 06:19:23 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 08 Aug 2017 08:19:23 +0200 Subject: [ghc-steering-committee] Proposal format ambiguity In-Reply-To: References: Message-ID: <1502173163.1908.1.camel@joachim-breitner.de> Hi, Am Montag, den 07.08.2017, 16:19 -0400 schrieb David Feuer: > In each case, it is unclear whether the way the proposal addresses > the original problem should appear in the proposed change > specification section or the effects and interactions section. well spotted. Do you have a recommendation for a better wording? You can submit a pull request (that would not be a real proposal, just something I then merge :-) > Minor side note: the title of the first section has a typo, > "propsoal". fixed. 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 Sun Aug 13 13:31:45 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 13 Aug 2017 15:31:45 +0200 Subject: [ghc-steering-committee] Please review: deriving for empty, Shepherd: Iavor Diatchki Message-ID: <1502631105.5576.1.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/63 was brought before the committee, by Ryan Scott. I propose Iavor Diachki as the Shepherd. 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. -- Joachim “nomeata” Breitner mail at joachim-breitner.de https://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 Mon Aug 14 18:21:45 2017 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 14 Aug 2017 18:21:45 +0000 Subject: [ghc-steering-committee] Please review: deriving for empty, Shepherd: Iavor Diatchki In-Reply-To: <1502631105.5576.1.camel@joachim-breitner.de> References: <1502631105.5576.1.camel@joachim-breitner.de> Message-ID: Hello all, I just read through this proposal, and in my mind it proposes two things: 1. Make the `deriving` syntax more consistent. Currently GHC disallows most, but not all, deriving clauses on empty declarations, but it will happily derive the instances using a stand-alone deriving declarations. The proposal suggests to simply allow `deriving` clauses on empty `data` declarations, and I agree. 2. Make the derived code for empty data declarations a bit more consistent. This is my summary of the proposed changes: 2.1. Eta-expand the generated code, so that if we are going the produce "bottom", we do so at the correct type (e.g. `showsPrec p x = ...` instead of `showsPrec = error ...`) To me this seems quite reasonable, and is what I'd expect. 2.2. When there is no meaningful result, use empty-case on the datatype, rather than `error` I think that this is a clear win, as it does not pollute the errors: the only value of a void type would be some sort of an error, and if we generate a definition using `error`, we give GHC a choice, where it could report either the original one, or the new one. I think it is better to avoid this and just keep the original one, as it is likely to be more useful. 2.3. Be "maximally defined" when there is a reasonable default value (e.g., return `True` for `Eq`, or `mempty` for `Foldable`). I am most ambivalent on this one is it seems weird to compare "bottom" values and get `True` as a result. However, according to the comments on the proposal, this sort of thing can be occasionally useful for some strange recursive definitions. I have not encountered such examples, but I don't really think it matters very much, and perhaps it'd be useful to someone. 2.4 Other misc. fixes: apparently the derived instance for `Read` on an empty type currently requires `parens`, which seems odd. The proposal suggests that the parsing should just fail, which to me makes sense. Based on that, I'd suggest that we accept the proposal. What do other folks think? -Iavor On Sun, Aug 13, 2017 at 6:32 AM Joachim Breitner wrote: > Dear Committee, > > this is your secretary speaking: > > https://github.com/ghc-proposals/ghc-proposals/pull/63 > was brought before the committee, by Ryan Scott. > > I propose Iavor Diachki as the Shepherd. > > 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. > -- > Joachim “nomeata” Breitner > mail at joachim-breitner.de > https://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 rae at cs.brynmawr.edu Mon Aug 14 20:27:40 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 14 Aug 2017 16:27:40 -0400 Subject: [ghc-steering-committee] Please review: deriving for empty, Shepherd: Iavor Diatchki In-Reply-To: References: <1502631105.5576.1.camel@joachim-breitner.de> Message-ID: <5C396B7E-EA87-4F69-A582-3DD4DD723B5B@cs.brynmawr.edu> I agree that we should accept the proposal, but there is a small snag: this proposal deviates from the Haskell 2010 Report, which (to me) clearly disallows `deriving` for empty datatypes. The proposal does not introduce a new language extension to control the new behavior, instead piggybacking on EmptyDataDecls. The only problem is that EmptyDataDecls is part of Haskell2010. Thus, this proposal marks yet one more way that GHC -XHaskell2010 will deviate from the Report. So, I'm unequivocally in support of this proposal if we have a new -XEmptyDataDeriving (or some such), and equivocally in support of the proposal without a new extension. Richard > On Aug 14, 2017, at 2:21 PM, Iavor Diatchki wrote: > > Hello all, > > I just read through this proposal, and in my mind it proposes two things: > > 1. Make the `deriving` syntax more consistent. Currently GHC disallows most, but not all, deriving clauses on empty declarations, but it will happily derive the instances using a stand-alone deriving declarations. The proposal suggests to simply allow `deriving` clauses on empty `data` declarations, and I agree. > > 2. Make the derived code for empty data declarations a bit more consistent. This is my summary of the proposed changes: > > 2.1. Eta-expand the generated code, so that if we are going the produce "bottom", we do so at the correct type (e.g. `showsPrec p x = ...` instead of `showsPrec = error ...`) > To me this seems quite reasonable, and is what I'd expect. > > 2.2. When there is no meaningful result, use empty-case on the datatype, rather than `error` > I think that this is a clear win, as it does not pollute the errors: the only value of a void type would be some sort of an error, and if we generate a definition using `error`, we give GHC a choice, where it could report either the original one, or the new one. I think it is better to avoid this and just keep the original one, as it is likely to be more useful. > > 2.3. Be "maximally defined" when there is a reasonable default value (e.g., return `True` for `Eq`, or `mempty` for `Foldable`). > I am most ambivalent on this one is it seems weird to compare "bottom" values and get `True` as a result. However, according to the comments on the proposal, this sort of thing can be occasionally useful for some strange recursive definitions. I have not encountered such examples, but I don't really think it matters very much, and perhaps it'd be useful to someone. > > 2.4 Other misc. fixes: apparently the derived instance for `Read` on an empty type currently requires `parens`, which seems odd. The proposal suggests that the parsing should just fail, which to me makes sense. > > > Based on that, I'd suggest that we accept the proposal. What do other folks think? > > -Iavor > > > > > > > > > > On Sun, Aug 13, 2017 at 6:32 AM Joachim Breitner > wrote: > Dear Committee, > > this is your secretary speaking: > > https://github.com/ghc-proposals/ghc-proposals/pull/63 > was brought before the committee, by Ryan Scott. > > I propose Iavor Diachki as the Shepherd. > > 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. > -- > Joachim “nomeata” Breitner > mail at joachim-breitner.de > https://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 > _______________________________________________ > 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 Tue Aug 15 00:13:08 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Tue, 15 Aug 2017 10:13:08 +1000 Subject: [ghc-steering-committee] Please review: deriving for empty, Shepherd: Iavor Diatchki In-Reply-To: <5C396B7E-EA87-4F69-A582-3DD4DD723B5B@cs.brynmawr.edu> References: <1502631105.5576.1.camel@joachim-breitner.de> <5C396B7E-EA87-4F69-A582-3DD4DD723B5B@cs.brynmawr.edu> Message-ID: <879F4E3A-93C8-4BB7-9E85-B6A4E6D5C05B@justtesting.org> I agree with Richard on both counts. It is unfortunate to have to introduce a new language extension, but it seems the right thing to do here. Manuel > Richard Eisenberg : > > I agree that we should accept the proposal, but there is a small snag: this proposal deviates from the Haskell 2010 Report, which (to me) clearly disallows `deriving` for empty datatypes. The proposal does not introduce a new language extension to control the new behavior, instead piggybacking on EmptyDataDecls. The only problem is that EmptyDataDecls is part of Haskell2010. Thus, this proposal marks yet one more way that GHC -XHaskell2010 will deviate from the Report. > > So, I'm unequivocally in support of this proposal if we have a new -XEmptyDataDeriving (or some such), and equivocally in support of the proposal without a new extension. > > Richard > >> On Aug 14, 2017, at 2:21 PM, Iavor Diatchki > wrote: >> >> Hello all, >> >> I just read through this proposal, and in my mind it proposes two things: >> >> 1. Make the `deriving` syntax more consistent. Currently GHC disallows most, but not all, deriving clauses on empty declarations, but it will happily derive the instances using a stand-alone deriving declarations. The proposal suggests to simply allow `deriving` clauses on empty `data` declarations, and I agree. >> >> 2. Make the derived code for empty data declarations a bit more consistent. This is my summary of the proposed changes: >> >> 2.1. Eta-expand the generated code, so that if we are going the produce "bottom", we do so at the correct type (e.g. `showsPrec p x = ...` instead of `showsPrec = error ...`) >> To me this seems quite reasonable, and is what I'd expect. >> >> 2.2. When there is no meaningful result, use empty-case on the datatype, rather than `error` >> I think that this is a clear win, as it does not pollute the errors: the only value of a void type would be some sort of an error, and if we generate a definition using `error`, we give GHC a choice, where it could report either the original one, or the new one. I think it is better to avoid this and just keep the original one, as it is likely to be more useful. >> >> 2.3. Be "maximally defined" when there is a reasonable default value (e.g., return `True` for `Eq`, or `mempty` for `Foldable`). >> I am most ambivalent on this one is it seems weird to compare "bottom" values and get `True` as a result. However, according to the comments on the proposal, this sort of thing can be occasionally useful for some strange recursive definitions. I have not encountered such examples, but I don't really think it matters very much, and perhaps it'd be useful to someone. >> >> 2.4 Other misc. fixes: apparently the derived instance for `Read` on an empty type currently requires `parens`, which seems odd. The proposal suggests that the parsing should just fail, which to me makes sense. >> >> >> Based on that, I'd suggest that we accept the proposal. What do other folks think? >> >> -Iavor >> >> >> >> >> >> >> >> >> >> On Sun, Aug 13, 2017 at 6:32 AM Joachim Breitner > wrote: >> Dear Committee, >> >> this is your secretary speaking: >> >> https://github.com/ghc-proposals/ghc-proposals/pull/63 >> was brought before the committee, by Ryan Scott. >> >> I propose Iavor Diachki as the Shepherd. >> >> 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. >> -- >> Joachim “nomeata” Breitner >> mail at joachim-breitner.de >> https://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 >> _______________________________________________ >> 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 Wed Aug 16 18:19:11 2017 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 16 Aug 2017 18:19:11 +0000 Subject: [ghc-steering-committee] Please review: deriving for empty, Shepherd: Iavor Diatchki In-Reply-To: <879F4E3A-93C8-4BB7-9E85-B6A4E6D5C05B@justtesting.org> References: <1502631105.5576.1.camel@joachim-breitner.de> <5C396B7E-EA87-4F69-A582-3DD4DD723B5B@cs.brynmawr.edu> <879F4E3A-93C8-4BB7-9E85-B6A4E6D5C05B@justtesting.org> Message-ID: I don't have a strong opinion about the pragma issue---to me this kind of divergence from Haskell 2010 is not important, as I really don't see what could possibly go wrong if you were to accidentally accept a program with a deriving clause on an empty data declaration. If another language pragma would be useful to someone though, I certainly don't mind. More generally, though, I have a feeling that perhaps we should consolidate the language pragmas a little, rather than adding more overlapping ones, especially with pragmas like `EmptyDataDecls`, which are essentially obsolete, given that the feature is in Haskell 2010, and there doesn't seem to be a particularly compelling reason to disable it. -Iavor On Mon, Aug 14, 2017 at 5:13 PM Manuel M T Chakravarty wrote: > I agree with Richard on both counts. It is unfortunate to have to > introduce a new language extension, but it seems the right thing to do here. > > Manuel > > > Richard Eisenberg : > > > I agree that we should accept the proposal, but there is a small snag: > this proposal deviates from the Haskell 2010 Report, which (to me) clearly > disallows `deriving` for empty datatypes. The proposal does not introduce a > new language extension to control the new behavior, instead piggybacking on > EmptyDataDecls. The only problem is that EmptyDataDecls is part of > Haskell2010. Thus, this proposal marks yet one more way that GHC > -XHaskell2010 will deviate from the Report. > > So, I'm unequivocally in support of this proposal if we have a new > -XEmptyDataDeriving (or some such), and equivocally in support of the > proposal without a new extension. > > Richard > > On Aug 14, 2017, at 2:21 PM, Iavor Diatchki > wrote: > > Hello all, > > I just read through this proposal, and in my mind it proposes two things: > > 1. Make the `deriving` syntax more consistent. Currently GHC disallows > most, but not all, deriving clauses on empty declarations, but it will > happily derive the instances using a stand-alone deriving declarations. > The proposal suggests to simply allow `deriving` clauses on empty `data` > declarations, and I agree. > > 2. Make the derived code for empty data declarations a bit more > consistent. This is my summary of the proposed changes: > > 2.1. Eta-expand the generated code, so that if we are going the > produce "bottom", we do so at the correct type (e.g. `showsPrec p x = ...` > instead of `showsPrec = error ...`) > To me this seems quite reasonable, and is what I'd expect. > > 2.2. When there is no meaningful result, use empty-case on the > datatype, rather than `error` > I think that this is a clear win, as it does not pollute > the errors: the only value of a void type would be some sort of an error, > and if we generate a definition using `error`, we give GHC a choice, where > it could report either the original one, or the new one. I think it is > better to avoid this and just keep the original one, as it is likely to be > more useful. > > 2.3. Be "maximally defined" when there is a reasonable default > value (e.g., return `True` for `Eq`, or `mempty` for `Foldable`). > I am most ambivalent on this one is it seems weird to > compare "bottom" values and get `True` as a result. However, according to > the comments on the proposal, this sort of thing can be occasionally useful > for some strange recursive definitions. I have not encountered such > examples, but I don't really think it matters very much, and perhaps it'd > be useful to someone. > > 2.4 Other misc. fixes: apparently the derived instance for `Read` > on an empty type currently requires `parens`, which seems odd. The > proposal suggests that the parsing should just fail, which to me makes > sense. > > > Based on that, I'd suggest that we accept the proposal. What do other > folks think? > > -Iavor > > > > > > > > > > On Sun, Aug 13, 2017 at 6:32 AM Joachim Breitner > wrote: > >> Dear Committee, >> >> this is your secretary speaking: >> >> https://github.com/ghc-proposals/ghc-proposals/pull/63 >> was brought before the committee, by Ryan Scott. >> >> I propose Iavor Diachki as the Shepherd. >> >> 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. >> -- >> Joachim “nomeata” Breitner >> mail at joachim-breitner.de >> https://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 >> > _______________________________________________ > 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 Wed Aug 16 22:11:44 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 17 Aug 2017 00:11:44 +0200 Subject: [ghc-steering-committee] Please review: deriving for empty, Shepherd: Iavor Diatchki In-Reply-To: References: <1502631105.5576.1.camel@joachim-breitner.de> <5C396B7E-EA87-4F69-A582-3DD4DD723B5B@cs.brynmawr.edu> <879F4E3A-93C8-4BB7-9E85-B6A4E6D5C05B@justtesting.org> Message-ID: <1502921504.8332.1.camel@joachim-breitner.de> Hi, Am Mittwoch, den 16.08.2017, 18:19 +0000 schrieb Iavor Diatchki: > I don't have a strong opinion about the pragma issue---to me this > kind of divergence from Haskell 2010 is not important, as I really > don't see what could possibly go wrong if you were to accidentally > accept a program with a deriving clause on an empty data declaration. that touches on a more fundamental question: How strict do we want to be with the “every divergence from the standard requires an extension” rule. My impression is that we have been rather strict with it, requiring extensions for things that are rather unambiguous (deriving various extra classes comes to mind). Before we diverge from this rule we should agree on the criteria as to when we allow ourselves to diverge. (E.g. something along the line: Divergence is only allowed around already rather obscure features. This would allow empty data declarations to derive stuff without language extension, but not allow additional derived type classes – but I just wrote this for illustrative purposes.) 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 rae at cs.brynmawr.edu Thu Aug 17 15:05:35 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Thu, 17 Aug 2017 11:05:35 -0400 Subject: [ghc-steering-committee] Please review: deriving for empty, Shepherd: Iavor Diatchki In-Reply-To: <1502921504.8332.1.camel@joachim-breitner.de> References: <1502631105.5576.1.camel@joachim-breitner.de> <5C396B7E-EA87-4F69-A582-3DD4DD723B5B@cs.brynmawr.edu> <879F4E3A-93C8-4BB7-9E85-B6A4E6D5C05B@justtesting.org> <1502921504.8332.1.camel@joachim-breitner.de> Message-ID: <08F19155-7E7D-4D85-A1E5-6EB2FA788296@cs.brynmawr.edu> > On Aug 16, 2017, at 6:11 PM, Joachim Breitner wrote: > > that touches on a more fundamental question: How strict do we want to > be with the “every divergence from the standard requires an extension” > rule. I think this is a great question to ask, but I would want more community feedback on this point than just us in the committee. My stance is that, absent this discussion, we should stay quite strict on that rule. (In the discussion, I would argue that adherence to the standard is less necessary.) Richard From cma at bitemyapp.com Thu Aug 17 16:47:01 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Thu, 17 Aug 2017 11:47:01 -0500 Subject: [ghc-steering-committee] Please review: deriving for empty, Shepherd: Iavor Diatchki In-Reply-To: <08F19155-7E7D-4D85-A1E5-6EB2FA788296@cs.brynmawr.edu> References: <1502631105.5576.1.camel@joachim-breitner.de> <5C396B7E-EA87-4F69-A582-3DD4DD723B5B@cs.brynmawr.edu> <879F4E3A-93C8-4BB7-9E85-B6A4E6D5C05B@justtesting.org> <1502921504.8332.1.camel@joachim-breitner.de> <08F19155-7E7D-4D85-A1E5-6EB2FA788296@cs.brynmawr.edu> Message-ID: I'd tend to agree that we should strictly respect the standard, eschewing "benign" augmentations. Part of my discomfort with this is my experience talking to programmers who hand-waved effects in general as benign. Without a formal definition of benign such as exists in the Semantic Versioning standard I'd just as soon not add something like this without putting it behind an extension. I'm a soft +1 on the proposal as an extension. On Thu, Aug 17, 2017 at 10:05 AM, Richard Eisenberg wrote: > >> On Aug 16, 2017, at 6:11 PM, Joachim Breitner wrote: >> >> that touches on a more fundamental question: How strict do we want to >> be with the “every divergence from the standard requires an extension” >> rule. > > I think this is a great question to ask, but I would want more community feedback on this point than just us in the committee. My stance is that, absent this discussion, we should stay quite strict on that rule. > > (In the discussion, I would argue that adherence to the standard is less necessary.) > > Richard > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Chris Allen Currently working on http://haskellbook.com From mail at joachim-breitner.de Sat Aug 19 11:16:12 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 19 Aug 2017 13:16:12 +0200 Subject: [ghc-steering-committee] Please review: or patterns, Shepherd: Manuel Chakravarty Message-ID: <1503141372.3940.1.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/43 was brought before the committee, by Ömer Sinan Ağacan. I propose Manuel Chakravarty as the Shepherd. 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. 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 Sat Aug 19 11:19:45 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 19 Aug 2017 13:19:45 +0200 Subject: [ghc-steering-committee] Status Message-ID: <1503141585.3940.3.camel@joachim-breitner.de> Hi, since the last status update two new proposals has come up for deliberation, and no proposals were decided. Open at the moment are: NOUNPACK on function arguments https://github.com/ghc-proposals/ghc-proposals/pull/46 Shepherd: Simon Marlow Status: There was more discussion on GitHub, and @treeowl will have a look if the proposal text is reflecting all that discussion. Lazy unboxed tuples https://github.com/ghc-proposals/ghc-proposals/pull/35 Shepherd: Ryan Newton Status: Waiting for Ryan to make a recommendation. Explicit foralls proposal https://github.com/ghc-proposals/ghc-proposals/pull/55 Shepherd: Simon Peyton Jones Status: Waiting for Simon to make a recommendation. Mutable constructor fields https://github.com/ghc-proposals/ghc-proposals/pull/8 Shepherd: Ryan Newton Status: Waiting for Ryan to make a recommendation. deriving for empty https://github.com/ghc-proposals/ghc-proposals/pull/63 Shepherd: Iavor Diatchki Status: Iavor recommends acceptance. There seems to be consensus so far, under the condition of a dedicate LANGUAGE flag for this. Or Patterns https://github.com/ghc-proposals/ghc-proposals/pull/43 Shepherd: Manuel Chakravarty Status: Waiting for Manuel to make a recommendation. 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%3Ap r+no%3Alabel Greetings, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- 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 marlowsd at gmail.com Wed Aug 23 08:43:56 2017 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 23 Aug 2017 09:43:56 +0100 Subject: [ghc-steering-committee] Please review: deriving for empty, Shepherd: Iavor Diatchki In-Reply-To: References: <1502631105.5576.1.camel@joachim-breitner.de> <5C396B7E-EA87-4F69-A582-3DD4DD723B5B@cs.brynmawr.edu> <879F4E3A-93C8-4BB7-9E85-B6A4E6D5C05B@justtesting.org> <1502921504.8332.1.camel@joachim-breitner.de> <08F19155-7E7D-4D85-A1E5-6EB2FA788296@cs.brynmawr.edu> Message-ID: +1 on the proposal, with an extension flag. I think we should continue to be strict about language extension flags. Extension flags allow the programmer to signal very clearly which features they're using, which allows us to write code that will be correctly rejected with a useful error message both by older versions of GHC and by hypothetical other compilers that don't support the extension. If we start to relax the policy of having extension flags, then it's hard to know where to stop. Yes we have already diverged from Haskell2010, but so far there was a compelling reason to do so in each case: e.g. we had no good way to support both versions of the Monad hierarchy, and for NondecreasingIndentation I think we had been accepting the extended syntax (without the flag) already in previous versions. Cheers Simon On 17 August 2017 at 17:47, Christopher Allen wrote: > I'd tend to agree that we should strictly respect the standard, > eschewing "benign" augmentations. Part of my discomfort with this is > my experience talking to programmers who hand-waved effects in general > as benign. Without a formal definition of benign such as exists in the > Semantic Versioning standard I'd just as soon not add something like > this without putting it behind an extension. > > I'm a soft +1 on the proposal as an extension. > > On Thu, Aug 17, 2017 at 10:05 AM, Richard Eisenberg > wrote: > > > >> On Aug 16, 2017, at 6:11 PM, Joachim Breitner > wrote: > >> > >> that touches on a more fundamental question: How strict do we want to > >> be with the “every divergence from the standard requires an extension” > >> rule. > > > > I think this is a great question to ask, but I would want more community > feedback on this point than just us in the committee. My stance is that, > absent this discussion, we should stay quite strict on that rule. > > > > (In the discussion, I would argue that adherence to the standard is less > necessary.) > > > > Richard > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > -- > Chris Allen > Currently working on http://haskellbook.com > _______________________________________________ > 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 Fri Aug 25 14:15:48 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 25 Aug 2017 14:15:48 +0000 Subject: [ghc-steering-committee] Explicit foralls Message-ID: Friends I propose that we accept the Explicit Foralls proposal. * No one objected * It makes the language more expressive and uniform * It fixes a long-standing ticket #2600 The only bump in the road is the double forall in RULES (see the Examples in the proposal). But that's not Ricahrd's fault, and the proposed solution seems reasonable. I move to accept. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sun Aug 27 18:16:28 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 27 Aug 2017 20:16:28 +0200 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Recommendation: Reject Message-ID: <1503857788.4643.2.camel@joachim-breitner.de> Dear Committee, Ryan Scott’s proposal to allow fixity declaration to explicitly target values or types has been brought before us: https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix.rst https://github.com/ghc-proposals/ghc-proposals/pull/65 I (the secretary) nominates myself as the shepherd, so I can right away continue giving a recommendation. I propose to reject this proposal. The main reasons are: * it is not clear if there is a real use case for this. Has anyone ever complained about the status quo? The proposal does not motivate the need for a change well enough. (There is a related bug in TH, but that bug can probably simply be  fixed.) * The status quo can be sold as a feature, rather than a short-coming. Namely that an operator has a fixed fixity, no matter what namespace it lives in. This matches morally what other languages do: In Gallina, fixity is assigned to names independent of their definition, AFAIK. * There is a non-trivial implementation and education overhead, a weight that is not pulled by the gains. If we’d design Haskell from scratch, my verdict might possibly be different (but maybe we wouldn’t even allow types and values to share names then…) Please contradict me or indicate consensus by staying silent. Greetings, Joachim -- Joachim “nomeata” Breitner mail at joachim-breitner.de https://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 Aug 28 01:44:26 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Mon, 28 Aug 2017 11:44:26 +1000 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Recommendation: Reject In-Reply-To: <1503857788.4643.2.camel@joachim-breitner.de> References: <1503857788.4643.2.camel@joachim-breitner.de> Message-ID: I am strongly against this proposal. User-defined fixities are already a feature that needs to be used with care, carrying the danger that the user of an API with ample operators with custom fixities needs to memorise many, often somewhat arbitrary numbers (i.e., precedence levels). Using different fixity declarations for the same operator name on the value and type level seems a sure way to increase confusion. I am very much against it. Manuel > Joachim Breitner : > > Dear Committee, > > Ryan Scott’s proposal to allow fixity declaration to explicitly target > values or types has been brought before us: > https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix.rst > https://github.com/ghc-proposals/ghc-proposals/pull/65 > > I (the secretary) nominates myself as the shepherd, so I can right away > continue giving a recommendation. > > I propose to reject this proposal. The main reasons are: > * it is not clear if there is a real use case for this. Has anyone > ever complained about the status quo? > The proposal does not motivate the need for a change well enough. > (There is a related bug in TH, but that bug can probably simply be > fixed.) > * The status quo can be sold as a feature, rather than a short-coming. > Namely that an operator has a fixed fixity, no matter what namespace > it lives in. > This matches morally what other languages do: In Gallina, fixity > is assigned to names independent of their definition, AFAIK. > * There is a non-trivial implementation and education overhead, a > weight that is not pulled by the gains. > > If we’d design Haskell from scratch, my verdict might possibly be > different (but maybe we wouldn’t even allow types and values to share > names then…) > > > Please contradict me or indicate consensus by staying silent. > > > Greetings, > Joachim > > -- > Joachim “nomeata” Breitner > mail at joachim-breitner.de > https://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 From iavor.diatchki at gmail.com Mon Aug 28 06:52:45 2017 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 28 Aug 2017 06:52:45 +0000 Subject: [ghc-steering-committee] Please review: deriving for empty, Shepherd: Iavor Diatchki In-Reply-To: References: <1502631105.5576.1.camel@joachim-breitner.de> <5C396B7E-EA87-4F69-A582-3DD4DD723B5B@cs.brynmawr.edu> <879F4E3A-93C8-4BB7-9E85-B6A4E6D5C05B@justtesting.org> <1502921504.8332.1.camel@joachim-breitner.de> <08F19155-7E7D-4D85-A1E5-6EB2FA788296@cs.brynmawr.edu> Message-ID: OK, I think we've heard from quite a few members of the committee, and the consensus appears to be that we should accept the proposed changes, but guard them with a separate language pragma. I'll post a comment to the thread, requesting that the author makes the change, and then mark it as accepted. -Iavor On Wed, Aug 23, 2017 at 11:44 AM Simon Marlow wrote: > +1 on the proposal, with an extension flag. > > I think we should continue to be strict about language extension flags. > Extension flags allow the programmer to signal very clearly which features > they're using, which allows us to write code that will be correctly > rejected with a useful error message both by older versions of GHC and by > hypothetical other compilers that don't support the extension. > > If we start to relax the policy of having extension flags, then it's hard > to know where to stop. Yes we have already diverged from Haskell2010, but > so far there was a compelling reason to do so in each case: e.g. we had no > good way to support both versions of the Monad hierarchy, and for > NondecreasingIndentation I think we had been accepting the extended syntax > (without the flag) already in previous versions. > > Cheers > Simon > > > On 17 August 2017 at 17:47, Christopher Allen wrote: > >> I'd tend to agree that we should strictly respect the standard, >> eschewing "benign" augmentations. Part of my discomfort with this is >> my experience talking to programmers who hand-waved effects in general >> as benign. Without a formal definition of benign such as exists in the >> Semantic Versioning standard I'd just as soon not add something like >> this without putting it behind an extension. >> >> I'm a soft +1 on the proposal as an extension. >> >> On Thu, Aug 17, 2017 at 10:05 AM, Richard Eisenberg >> wrote: >> > >> >> On Aug 16, 2017, at 6:11 PM, Joachim Breitner < >> mail at joachim-breitner.de> wrote: >> >> >> >> that touches on a more fundamental question: How strict do we want to >> >> be with the “every divergence from the standard requires an extension” >> >> rule. >> > >> > I think this is a great question to ask, but I would want more >> community feedback on this point than just us in the committee. My stance >> is that, absent this discussion, we should stay quite strict on that rule. >> > >> > (In the discussion, I would argue that adherence to the standard is >> less necessary.) >> > >> > Richard >> > _______________________________________________ >> > ghc-steering-committee mailing list >> > ghc-steering-committee at haskell.org >> > >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> >> >> >> -- >> Chris Allen >> Currently working on http://haskellbook.com >> _______________________________________________ >> 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 Mon Aug 28 09:05:52 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 28 Aug 2017 09:05:52 +0000 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Recommendation: Reject In-Reply-To: <1503857788.4643.2.camel@joachim-breitner.de> References: <1503857788.4643.2.camel@joachim-breitner.de> Message-ID: I don't have a strong opinion either way. The strongly reason in favour is encapsulated in Richard's comment https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-319054892 which points out that the two T's are entirely unrelated. I had not fully realised this, but in fact it is /already/ possible to have different fixities for a single lexeme T; a concrete example is here https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-325294776 I added another comment https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-325301080 that tries to separate the AST issue from the source-code issue. I do think we should make the internal change; but I’m unconvinced it’s worth the faff to solve the source-level issue. Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces at haskell.org] On Behalf Of Joachim Breitner | Sent: 27 August 2017 19:16 | To: ghc-steering-committee at haskell.org | Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), | Recommendation: Reject | | Dear Committee, | | Ryan Scott’s proposal to allow fixity declaration to explicitly target | values or types has been brought before us: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% | 2FRyanGlScott%2Fghc-proposals%2Fblob%2Ftype-infix%2F0000-type- | infix.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4e | d77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdat | a=xa8HXiRK3uYOjGun7UUL3sKDVFvBVTFnXewe15pBGds%3D&reserved=0 | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% | 2Fghc-proposals%2Fghc- | proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4 | f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63639454614 | 6778107&sdata=f5g17%2FpJdVe4vuwOAhrphyvXJakPFMS3yYZsi0sNG00%3D&reserved=0 | | I (the secretary) nominates myself as the shepherd, so I can right away | continue giving a recommendation. | | I propose to reject this proposal. The main reasons are: | * it is not clear if there is a real use case for this. Has anyone | ever complained about the status quo? | The proposal does not motivate the need for a change well enough. | (There is a related bug in TH, but that bug can probably simply be | fixed.) | * The status quo can be sold as a feature, rather than a short-coming. | Namely that an operator has a fixed fixity, no matter what namespace | it lives in. | This matches morally what other languages do: In Gallina, fixity | is assigned to names independent of their definition, AFAIK. | * There is a non-trivial implementation and education overhead, a | weight that is not pulled by the gains. | | If we’d design Haskell from scratch, my verdict might possibly be different | (but maybe we wouldn’t even allow types and values to share names then…) | | | Please contradict me or indicate consensus by staying silent. | | | Greetings, | Joachim | | -- | Joachim “nomeata” Breitner | mail at joachim-breitner.de | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim | - | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b | 08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107 | &sdata=PLDAZw6uCBkzRl7cjF00IomTmEAuqDKd7NNjbPWkpeE%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Mon Aug 28 12:41:32 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 28 Aug 2017 08:41:32 -0400 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Recommendation: Reject In-Reply-To: References: <1503857788.4643.2.camel@joachim-breitner.de> Message-ID: Unsurprisingly, I'm in favor of this proposal and do not wish to reject. To me, the wart on the language is that we can use the same string for a term-level name and a potentially unrelated type-level name. Of course, this has served many people well, but it does create a certain awkwardness in places (and confusion for beginners!). As long as we have the possibility of one string representing two potentially unrelated names, it seems to be a weakness in expressiveness not to be able to assign different fixities to the names. (And indeed we *can* assign different fixities, as long as we do so in different modules.) On the other hand, I am sensitive about all those other raw fish that need frying... Richard > On Aug 28, 2017, at 5:05 AM, Simon Peyton Jones wrote: > > I don't have a strong opinion either way. The strongly reason in favour is encapsulated in Richard's comment > https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-319054892 > which points out that the two T's are entirely unrelated. > > I had not fully realised this, but in fact it is /already/ possible to have different fixities for a single lexeme T; a concrete example is here > https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-325294776 > > I added another comment > https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-325301080 > that tries to separate the AST issue from the source-code issue. I do think we should make the internal change; but I’m unconvinced it’s worth the faff to solve the source-level issue. > > Simon > > > | -----Original Message----- > | From: ghc-steering-committee [mailto:ghc-steering-committee- > | bounces at haskell.org ] On Behalf Of Joachim Breitner > | Sent: 27 August 2017 19:16 > | To: ghc-steering-committee at haskell.org > | Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), > | Recommendation: Reject > | > | Dear Committee, > | > | Ryan Scott’s proposal to allow fixity declaration to explicitly target > | values or types has been brought before us: > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% > |  2FRyanGlScott%2Fghc-proposals%2Fblob%2Ftype-infix%2F0000-type- > |  infix.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4e > |  d77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdat > |  a=xa8HXiRK3uYOjGun7UUL3sKDVFvBVTFnXewe15pBGds%3D&reserved=0 > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% > |  2Fghc-proposals%2Fghc- > |  proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4 > |  f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63639454614 > |  6778107&sdata=f5g17%2FpJdVe4vuwOAhrphyvXJakPFMS3yYZsi0sNG00%3D&reserved=0 > | > | I (the secretary) nominates myself as the shepherd, so I can right away > | continue giving a recommendation. > | > | I propose to reject this proposal. The main reasons are: > | * it is not clear if there is a real use case for this. Has anyone > | ever complained about the status quo? > | The proposal does not motivate the need for a change well enough. > | (There is a related bug in TH, but that bug can probably simply be > | fixed.) > | * The status quo can be sold as a feature, rather than a short-coming. > | Namely that an operator has a fixed fixity, no matter what namespace > | it lives in. > | This matches morally what other languages do: In Gallina, fixity > | is assigned to names independent of their definition, AFAIK. > | * There is a non-trivial implementation and education overhead, a > | weight that is not pulled by the gains. > | > | If we’d design Haskell from scratch, my verdict might possibly be different > | (but maybe we wouldn’t even allow types and values to share names then…) > | > | > | Please contradict me or indicate consensus by staying silent. > | > | > | Greetings, > | Joachim > | > | -- > | Joachim “nomeata” Breitner > | mail at joachim-breitner.de > | > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim > |  - > |  breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b > |  08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107 > |  &sdata=PLDAZw6uCBkzRl7cjF00IomTmEAuqDKd7NNjbPWkpeE%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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From chak at justtesting.org Tue Aug 29 00:30:28 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Tue, 29 Aug 2017 10:30:28 +1000 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Recommendation: Reject In-Reply-To: References: <1503857788.4643.2.camel@joachim-breitner.de> Message-ID: <52B10519-E87B-44CF-AA2A-F9CBD00E5E22@justtesting.org> IMHO, it is a bug that you can provide different fixities in different modules and we should fix that bug. Manuel > Richard Eisenberg : > > Unsurprisingly, I'm in favor of this proposal and do not wish to reject. > > To me, the wart on the language is that we can use the same string for a term-level name and a potentially unrelated type-level name. Of course, this has served many people well, but it does create a certain awkwardness in places (and confusion for beginners!). As long as we have the possibility of one string representing two potentially unrelated names, it seems to be a weakness in expressiveness not to be able to assign different fixities to the names. (And indeed we *can* assign different fixities, as long as we do so in different modules.) > > On the other hand, I am sensitive about all those other raw fish that need frying... > > Richard > >> On Aug 28, 2017, at 5:05 AM, Simon Peyton Jones > wrote: >> >> I don't have a strong opinion either way. The strongly reason in favour is encapsulated in Richard's comment >> https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-319054892 >> which points out that the two T's are entirely unrelated. >> >> I had not fully realised this, but in fact it is /already/ possible to have different fixities for a single lexeme T; a concrete example is here >> https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-325294776 >> >> I added another comment >> https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-325301080 >> that tries to separate the AST issue from the source-code issue. I do think we should make the internal change; but I’m unconvinced it’s worth the faff to solve the source-level issue. >> >> Simon >> >> >> | -----Original Message----- >> | From: ghc-steering-committee [mailto:ghc-steering-committee- >> | bounces at haskell.org ] On Behalf Of Joachim Breitner >> | Sent: 27 August 2017 19:16 >> | To: ghc-steering-committee at haskell.org >> | Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), >> | Recommendation: Reject >> | >> | Dear Committee, >> | >> | Ryan Scott’s proposal to allow fixity declaration to explicitly target >> | values or types has been brought before us: >> | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% >> |  2FRyanGlScott%2Fghc-proposals%2Fblob%2Ftype-infix%2F0000-type- >> |  infix.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4e >> |  d77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdat >> |  a=xa8HXiRK3uYOjGun7UUL3sKDVFvBVTFnXewe15pBGds%3D&reserved=0 >> | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% >> |  2Fghc-proposals%2Fghc- >> |  proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4 >> |  f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63639454614 >> |  6778107&sdata=f5g17%2FpJdVe4vuwOAhrphyvXJakPFMS3yYZsi0sNG00%3D&reserved=0 >> | >> | I (the secretary) nominates myself as the shepherd, so I can right away >> | continue giving a recommendation. >> | >> | I propose to reject this proposal. The main reasons are: >> | * it is not clear if there is a real use case for this. Has anyone >> | ever complained about the status quo? >> | The proposal does not motivate the need for a change well enough. >> | (There is a related bug in TH, but that bug can probably simply be >> | fixed.) >> | * The status quo can be sold as a feature, rather than a short-coming. >> | Namely that an operator has a fixed fixity, no matter what namespace >> | it lives in. >> | This matches morally what other languages do: In Gallina, fixity >> | is assigned to names independent of their definition, AFAIK. >> | * There is a non-trivial implementation and education overhead, a >> | weight that is not pulled by the gains. >> | >> | If we’d design Haskell from scratch, my verdict might possibly be different >> | (but maybe we wouldn’t even allow types and values to share names then…) >> | >> | >> | Please contradict me or indicate consensus by staying silent. >> | >> | >> | Greetings, >> | Joachim >> | >> | -- >> | Joachim “nomeata” Breitner >> | mail at joachim-breitner.de >> | >> | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim >> |  - >> |  breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b >> |  08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107 >> |  &sdata=PLDAZw6uCBkzRl7cjF00IomTmEAuqDKd7NNjbPWkpeE%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 Aug 29 06:18:15 2017 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 29 Aug 2017 06:18:15 +0000 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Recommendation: Reject In-Reply-To: <52B10519-E87B-44CF-AA2A-F9CBD00E5E22@justtesting.org> References: <1503857788.4643.2.camel@joachim-breitner.de> <52B10519-E87B-44CF-AA2A-F9CBD00E5E22@justtesting.org> Message-ID: Hello, I think that we should accept this proposal. My reasoning is as follows: * in traditional Haskell (e.g., 98, 2010) fixities are associated with specific declarations, thus the same name always has the same fixity, no matter in which module it is used. * I think that this is not a bug, but a feature: fixities would be basically unusable if they kept changiing, or somehow all libraries had to agree on using a specific fixity ahead of time---even when they use the same name for completely different purposes (let alone type vs. value). * I find the current design for `TypeOprators` to be confusing, as a single fixity declaration, sets the fixties of two completely unrelated names---one in the value namespace and one in the type namespace: assuming that these two have anything to with each other seems to be a mistake. * the propsal suggests a rather natural way to resolve this. -Iavor On Tue, Aug 29, 2017 at 3:30 AM Manuel M T Chakravarty wrote: > IMHO, it is a bug that you can provide different fixities in different > modules and we should fix that bug. > > Manuel > > Richard Eisenberg : > > > Unsurprisingly, I'm in favor of this proposal and do not wish to reject. > > To me, the wart on the language is that we can use the same string for a > term-level name and a potentially unrelated type-level name. Of course, > this has served many people well, but it does create a certain awkwardness > in places (and confusion for beginners!). As long as we have the > possibility of one string representing two potentially unrelated names, it > seems to be a weakness in expressiveness not to be able to assign different > fixities to the names. (And indeed we *can* assign different fixities, as > long as we do so in different modules.) > > On the other hand, I am sensitive about all those other raw fish that need > frying... > > Richard > > On Aug 28, 2017, at 5:05 AM, Simon Peyton Jones > wrote: > > I don't have a strong opinion either way. The strongly reason in favour is > encapsulated in Richard's comment > > https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-319054892 > which points out that the two T's are entirely unrelated. > > I had not fully realised this, but in fact it is /already/ possible to > have different fixities for a single lexeme T; a concrete example is here > > https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-325294776 > > I added another comment > > https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-325301080 > that tries to separate the AST issue from the source-code issue. I do > think we should make the internal change; but I’m unconvinced it’s worth > the faff to solve the source-level issue. > > Simon > > > | -----Original Message----- > | From: ghc-steering-committee [mailto:ghc-steering-committee- > | bounces at haskell.org] On Behalf Of Joachim Breitner > | Sent: 27 August 2017 19:16 > | To: ghc-steering-committee at haskell.org > | Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), > | Recommendation: Reject > | > | Dear Committee, > | > | Ryan Scott’s proposal to allow fixity declaration to explicitly target > | values or types has been brought before us: > | > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% > > | 2FRyanGlScott%2Fghc-proposals%2Fblob%2Ftype-infix%2F0000-type- > > | > infix.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4e > > | > d77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdat > > | a=xa8HXiRK3uYOjGun7UUL3sKDVFvBVTFnXewe15pBGds%3D&reserved=0 > > | > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% > > | 2Fghc-proposals%2Fghc- > > | > proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4 > > | > f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63639454614 > > | > 6778107&sdata=f5g17%2FpJdVe4vuwOAhrphyvXJakPFMS3yYZsi0sNG00%3D&reserved=0 > > | > | I (the secretary) nominates myself as the shepherd, so I can right away > | continue giving a recommendation. > | > | I propose to reject this proposal. The main reasons are: > | * it is not clear if there is a real use case for this. Has anyone > | ever complained about the status quo? > | The proposal does not motivate the need for a change well enough. > | (There is a related bug in TH, but that bug can probably simply be > | fixed.) > | * The status quo can be sold as a feature, rather than a short-coming. > | Namely that an operator has a fixed fixity, no matter what namespace > | it lives in. > | This matches morally what other languages do: In Gallina, fixity > | is assigned to names independent of their definition, AFAIK. > | * There is a non-trivial implementation and education overhead, a > | weight that is not pulled by the gains. > | > | If we’d design Haskell from scratch, my verdict might possibly be > different > | (but maybe we wouldn’t even allow types and values to share names then…) > | > | > | Please contradict me or indicate consensus by staying silent. > | > | > | Greetings, > | Joachim > | > | -- > | Joachim “nomeata” Breitner > | mail at joachim-breitner.de > | > | > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim > > | - > > | > breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b > > | > 08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107 > > | &sdata=PLDAZw6uCBkzRl7cjF00IomTmEAuqDKd7NNjbPWkpeE%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 Tue Aug 29 08:42:44 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 29 Aug 2017 08:42:44 +0000 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Recommendation: Reject In-Reply-To: <52B10519-E87B-44CF-AA2A-F9CBD00E5E22@justtesting.org> References: <1503857788.4643.2.camel@joachim-breitner.de> <52B10519-E87B-44CF-AA2A-F9CBD00E5E22@justtesting.org> Message-ID: IMHO, it is a bug that you can provide different fixities in different modules and we should fix that bug. Doing so would require a design in its own right – a new GHC proposal in fact. The Haskell 2010 report specifically specifies that fixity is a property of an entity, not a lexeme. Remember those two modules might come from utterly different libraries A and B, written by different authors at different times. We can hardly say that it’s an error to use them together! S From: Manuel M T Chakravarty [mailto:chak at justtesting.org] Sent: 29 August 2017 01:30 To: Richard Eisenberg Cc: Simon Peyton Jones ; ghc-steering-committee at haskell.org; Joachim Breitner Subject: Re: [ghc-steering-committee] Proposal: Type Fixity (#65), Recommendation: Reject IMHO, it is a bug that you can provide different fixities in different modules and we should fix that bug. Manuel Richard Eisenberg >: Unsurprisingly, I'm in favor of this proposal and do not wish to reject. To me, the wart on the language is that we can use the same string for a term-level name and a potentially unrelated type-level name. Of course, this has served many people well, but it does create a certain awkwardness in places (and confusion for beginners!). As long as we have the possibility of one string representing two potentially unrelated names, it seems to be a weakness in expressiveness not to be able to assign different fixities to the names. (And indeed we *can* assign different fixities, as long as we do so in different modules.) On the other hand, I am sensitive about all those other raw fish that need frying... Richard On Aug 28, 2017, at 5:05 AM, Simon Peyton Jones > wrote: I don't have a strong opinion either way. The strongly reason in favour is encapsulated in Richard's comment https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-319054892 which points out that the two T's are entirely unrelated. I had not fully realised this, but in fact it is /already/ possible to have different fixities for a single lexeme T; a concrete example is here https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-325294776 I added another comment https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-325301080 that tries to separate the AST issue from the source-code issue. I do think we should make the internal change; but I’m unconvinced it’s worth the faff to solve the source-level issue. Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces at haskell.org] On Behalf Of Joachim Breitner | Sent: 27 August 2017 19:16 | To: ghc-steering-committee at haskell.org | Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), | Recommendation: Reject | | Dear Committee, | | Ryan Scott’s proposal to allow fixity declaration to explicitly target | values or types has been brought before us: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% | 2FRyanGlScott%2Fghc-proposals%2Fblob%2Ftype-infix%2F0000-type- | infix.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4e | d77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdat | a=xa8HXiRK3uYOjGun7UUL3sKDVFvBVTFnXewe15pBGds%3D&reserved=0 | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% | 2Fghc-proposals%2Fghc- | proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4 | f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63639454614 | 6778107&sdata=f5g17%2FpJdVe4vuwOAhrphyvXJakPFMS3yYZsi0sNG00%3D&reserved=0 | | I (the secretary) nominates myself as the shepherd, so I can right away | continue giving a recommendation. | | I propose to reject this proposal. The main reasons are: | * it is not clear if there is a real use case for this. Has anyone | ever complained about the status quo? | The proposal does not motivate the need for a change well enough. | (There is a related bug in TH, but that bug can probably simply be | fixed.) | * The status quo can be sold as a feature, rather than a short-coming. | Namely that an operator has a fixed fixity, no matter what namespace | it lives in. | This matches morally what other languages do: In Gallina, fixity | is assigned to names independent of their definition, AFAIK. | * There is a non-trivial implementation and education overhead, a | weight that is not pulled by the gains. | | If we’d design Haskell from scratch, my verdict might possibly be different | (but maybe we wouldn’t even allow types and values to share names then…) | | | Please contradict me or indicate consensus by staying silent. | | | Greetings, | Joachim | | -- | Joachim “nomeata” Breitner | mail at joachim-breitner.de | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim | - | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b | 08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107 | &sdata=PLDAZw6uCBkzRl7cjF00IomTmEAuqDKd7NNjbPWkpeE%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: