From bravit111 at gmail.com Fri Feb 1 14:57:59 2019 From: bravit111 at gmail.com (Vitaly Bragilevsky) Date: Fri, 1 Feb 2019 17:57:59 +0300 Subject: [ghc-steering-committee] Proposal #167 (Deprecated Entities): Request for comments Message-ID: Dear Committee, I was asked to shepherd the proposal #167 (Deprecated Entities, https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst). It is proposed to extend DEPRECATED pragma with the two specifiers to disambiguate deprecating named type-level and value-level things. Simon suggested another alternative to make DEPRECATED pragmas positional (in consistency with the deprecating modules). I like the positional alternative more, as it enables more fine-grained control over deprecated entities and can be extended to deprecating unnamed entities (like type class instances). It seems the author is okay with rewriting the proposal, but the current proposal is already implemented. So, the question is: do we want it quick or good? I am not ready to answer this question and come up with the recommendation on the proposal yet. Please, comment on the following issues: a) which form of the DEPRECATED pragma you prefer, b) do you see any potential drawbacks of the positional form, c) are there any caveats with deprecating instances. Your comments are very welcome either here or on GitHub ( https://github.com/ghc-proposals/ghc-proposals/pull/167). Thanks, Vitaly -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Fri Feb 1 18:04:09 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 1 Feb 2019 10:04:09 -0800 Subject: [ghc-steering-committee] Proposal #167 (Deprecated Entities): Request for comments In-Reply-To: References: Message-ID: Hello, this seems quite reasonable and I think we should accept it. I don't have a strong preference on if this is positional or not. If it is positional, it may be nice to associate it with a specific delcaration, so that you don't have to write the name twice. OTOH, I also see values in the ability to put all deprecation pragmas in one place, rather than sprinkling them throughout a declaration. -Iavor On Fri, Feb 1, 2019 at 6:58 AM Vitaly Bragilevsky wrote: > Dear Committee, > > I was asked to shepherd the proposal #167 (Deprecated Entities, > https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst). > It is proposed to extend DEPRECATED pragma with the two specifiers to > disambiguate deprecating named type-level and value-level things. Simon > suggested another alternative to make DEPRECATED pragmas positional (in > consistency with the deprecating modules). I like the positional > alternative more, as it enables more fine-grained control over deprecated > entities and can be extended to deprecating unnamed entities (like type > class instances). It seems the author is okay with rewriting the proposal, > but the current proposal is already implemented. So, the question is: do > we want it quick or good? I am not ready to answer this question and come > up with the recommendation on the proposal yet. > > Please, comment on the following issues: a) which form of the DEPRECATED > pragma you prefer, b) do you see any potential drawbacks of the positional > form, c) are there any caveats with deprecating instances. Your comments > are very welcome either here or on GitHub ( > https://github.com/ghc-proposals/ghc-proposals/pull/167). > > Thanks, > Vitaly > _______________________________________________ > 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 Sat Feb 2 10:01:19 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 02 Feb 2019 11:01:19 +0100 Subject: [ghc-steering-committee] Proposal #167 (Deprecated Entities): Request for comments In-Reply-To: References: Message-ID: <3e75b2a8940c0e4faa0736ba207749ea577088eb.camel@joachim-breitner.de> Hi, I have a similar notions. Either would work, both have downsides. Re positionally, I notice that the way GHC expects them to be placed is pretty rigid, and may make the code less nice to read, with a possibly large pragma between the constructor and the arguments. I find this to not fit well with the rest of the language, where we can even move type signatures away from the code if that improves readability. But the ability to deprecate instances is a strong argument in favor of a positional variant. TBH, all these problems (how to nicely place annotations of sorts next to many kinds of declarations) had to be answered for haddock already, so piggy-backing on that might be the best coarse of action, e.g. something along the lines of where DEPRECATED is followed by either | or ^, with the same meaning as for haddocks. This easily extends to allowing either positional or named pragmas, and leave it up to the user what they prefer: {-# DEPRECATED pattern Baz "Baz is deprecated too" #-} This is maybe a somewhat elaborate for “just” the DEPRECATED pragma, but we are solving a problem here will come up with other existing or future pragmas as well, so a generic solution that we are happy with and that can be applied uniformly would be nice. With this in mind, maybe we should accept the proposal with the named variant for now, and make “refined positional pragmas” a separate proposal that deals with a positional way of writing of all annotation- like pragmas. It is a pitty that ANN and DEPRECATED, although very similar in their needs of addressing modules, terms and types, have already diverged in how they do it (ANN module vs. positional DEPRECATED; a type qualifier for ANN, but no qualifiers for DEPRECATED, and more than one qualifier after this proposal). Cheers, Joachim Am Freitag, den 01.02.2019, 10:04 -0800 schrieb Iavor Diatchki: > Hello, > > this seems quite reasonable and I think we should accept it. I don't have a strong preference on if this is positional or not. If it is positional, it may be nice to associate it with a specific delcaration, so that you don't have to write the name twice. OTOH, I also see values in the ability to put all deprecation pragmas in one place, rather than sprinkling them throughout a declaration. > > -Iavor > > On Fri, Feb 1, 2019 at 6:58 AM Vitaly Bragilevsky wrote: > > Dear Committee, > > > > I was asked to shepherd the proposal #167 (Deprecated Entities, https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst). It is proposed to extend DEPRECATED pragma with the two specifiers to disambiguate deprecating named type-level and value-level things. Simon suggested another alternative to make DEPRECATED pragmas positional (in consistency with the deprecating modules). I like the positional alternative more, as it enables more fine-grained control over deprecated entities and can be extended to deprecating unnamed entities (like type class instances). It seems the author is okay with rewriting the proposal, but the current proposal is already implemented. So, the question is: do we want it quick or good? I am not ready to answer this question and come up with the recommendation on the proposal yet. > > > > Please, comment on the following issues: a) which form of the DEPRECATED pragma you prefer, b) do you see any potential drawbacks of the positional form, c) are there any caveats with deprecating instances. Your comments are very welcome either here or on GitHub (https://github.com/ghc-proposals/ghc-proposals/pull/167). > > > > Thanks, > > Vitaly > > _______________________________________________ > > 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 mail at joachim-breitner.de Sun Feb 3 14:13:22 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 03 Feb 2019 15:13:22 +0100 Subject: [ghc-steering-committee] Please review #203: PtrRep, Shepherd: Simon PJ Message-ID: <5e775525287dc2384256c485133ef49b97f1853d.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: PtrRep has been proposed by Andrew Martin: https://github.com/ghc-proposals/ghc-proposals/pull/203 https://github.com/andrewthad/ghc-proposals/blob/pointer_rep/proposals/0000-pointer-rep.rst I propose Simon PJ as the shepherd (he already glimpsed at it, so hopefully already has an opinion.) Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, 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 eric at seidel.io Sun Feb 3 15:45:44 2019 From: eric at seidel.io (Eric Seidel) Date: Sun, 03 Feb 2019 10:45:44 -0500 Subject: [ghc-steering-committee] Proposal #167 (Deprecated Entities): Request for comments In-Reply-To: <3e75b2a8940c0e4faa0736ba207749ea577088eb.camel@joachim-breitner.de> References: <3e75b2a8940c0e4faa0736ba207749ea577088eb.camel@joachim-breitner.de> Message-ID: <1549208744.1789639.1649829992.5A1CCE2B@webmail.messagingengine.com> I think I have a slight preference for the named variant. The positional variant feels like it would be a bit too noisy, especially if you're providing a nice descriptive message. I'm more bothered by the fact that the data/constructor tag has now become 'pattern', which feels to me like it should only apply to pattern synonyms. But according to https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-425736470 it sounds like that ship may have sailed already if we want to be consistent (which we should!). On Sat, Feb 2, 2019, at 05:01, Joachim Breitner wrote: > Hi, > > I have a similar notions. Either would work, both have downsides. > > Re positionally, I notice that the way GHC expects them to be placed is > pretty rigid, and may make the code less nice to read, with a possibly > large pragma between the constructor and the arguments. I find this to > not fit well with the rest of the language, where we can even move type > signatures away from the code if that improves readability. > > But the ability to deprecate instances is a strong argument in favor of > a positional variant. > > > TBH, all these problems (how to nicely place annotations of sorts next > to many kinds of declarations) had to be answered for haddock already, > so piggy-backing on that might be the best coarse of action, e.g. > something along the lines of > > where DEPRECATED is followed by either | or ^, with the same meaning as > for haddocks. > > This easily extends to allowing either positional or named pragmas, and > leave it up to the user what they prefer: > > {-# DEPRECATED pattern Baz "Baz is deprecated too" #-} > > > This is maybe a somewhat elaborate for “just” the DEPRECATED pragma, > but we are solving a problem here will come up with other existing or > future pragmas as well, so a generic solution that we are happy with > and that can be applied uniformly would be nice. > > > With this in mind, maybe we should accept the proposal with the named > variant for now, and make “refined positional pragmas” a separate > proposal that deals with a positional way of writing of all annotation- > like pragmas. > > > It is a pitty that ANN and DEPRECATED, although very similar in their > needs of addressing modules, terms and types, have already diverged in > how they do it (ANN module vs. positional DEPRECATED; a type qualifier > for ANN, but no qualifiers for DEPRECATED, and more than one qualifier > after this proposal). > > > Cheers, > Joachim > > > Am Freitag, den 01.02.2019, 10:04 -0800 schrieb Iavor Diatchki: > > Hello, > > > > this seems quite reasonable and I think we should accept it. I don't have a strong preference on if this is positional or not. If it is positional, it may be nice to associate it with a specific delcaration, so that you don't have to write the name twice. OTOH, I also see values in the ability to put all deprecation pragmas in one place, rather than sprinkling them throughout a declaration. > > > > -Iavor > > > > On Fri, Feb 1, 2019 at 6:58 AM Vitaly Bragilevsky wrote: > > > Dear Committee, > > > > > > I was asked to shepherd the proposal #167 (Deprecated Entities, https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst). It is proposed to extend DEPRECATED pragma with the two specifiers to disambiguate deprecating named type-level and value-level things. Simon suggested another alternative to make DEPRECATED pragmas positional (in consistency with the deprecating modules). I like the positional alternative more, as it enables more fine-grained control over deprecated entities and can be extended to deprecating unnamed entities (like type class instances). It seems the author is okay with rewriting the proposal, but the current proposal is already implemented. So, the question is: do we want it quick or good? I am not ready to answer this question and come up with the recommendation on the proposal yet. > > > > > > Please, comment on the following issues: a) which form of the DEPRECATED pragma you prefer, b) do you see any potential drawbacks of the positional form, c) are there any caveats with deprecating instances. Your comments are very welcome either here or on GitHub (https://github.com/ghc-proposals/ghc-proposals/pull/167). > > > > > > Thanks, > > > Vitaly > > > _______________________________________________ > > > 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 > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature) From mail at joachim-breitner.de Sun Feb 3 22:48:17 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 03 Feb 2019 23:48:17 +0100 Subject: [ghc-steering-committee] Please review #176: SCC Parsing, Shepherd: Simon M Message-ID: <60a52ca934167ab68ecab76bde5789f74e242181.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: Meaning-preserving parsing rules for SCC annotations has been proposed by Vladislav Zavialov: https://github.com/ghc-proposals/ghc-proposals/pull/176 https://github.com/int-index/ghc-proposals/blob/scc-parsing/proposals/0000-scc-parsing.rst I propose Simon Marlow as the shepherd (he already glimpsed at it, so hopefully already has an opinion.) Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, 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 Sun Feb 3 22:50:46 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 03 Feb 2019 23:50:46 +0100 Subject: [ghc-steering-committee] Proposal #167 (Deprecated Entities): Request for comments In-Reply-To: <1549208744.1789639.1649829992.5A1CCE2B@webmail.messagingengine.com> References: <3e75b2a8940c0e4faa0736ba207749ea577088eb.camel@joachim-breitner.de> <1549208744.1789639.1649829992.5A1CCE2B@webmail.messagingengine.com> Message-ID: <2f4721f409d074f753d5c8d439f946ca9a0a4cbe.camel@joachim-breitner.de> Hi, Am Sonntag, den 03.02.2019, 10:45 -0500 schrieb Eric Seidel: > I'm more bothered by the fact that the data/constructor tag has now > become 'pattern', which feels to me like it should only apply to > pattern synonyms. But according to > https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-425736470 > it sounds like that ship may have sailed already if we want to be > consistent (which we should!). We can maybe fix it consistently, and phase out “pattern” (make it an alias for whatever we choose) … but do we have an obviously appropriate name? Cheers, 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 eric at seidel.io Mon Feb 4 02:39:15 2019 From: eric at seidel.io (Eric Seidel) Date: Sun, 03 Feb 2019 21:39:15 -0500 Subject: [ghc-steering-committee] Proposal #167 (Deprecated Entities): Request for comments In-Reply-To: <2f4721f409d074f753d5c8d439f946ca9a0a4cbe.camel@joachim-breitner.de> References: <3e75b2a8940c0e4faa0736ba207749ea577088eb.camel@joachim-breitner.de> <1549208744.1789639.1649829992.5A1CCE2B@webmail.messagingengine.com> <2f4721f409d074f753d5c8d439f946ca9a0a4cbe.camel@joachim-breitner.de> Message-ID: <1549247955.1943852.1650103480.0C9B42AD@webmail.messagingengine.com> In https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst we already have an approved alternative: "value". On Sun, Feb 3, 2019, at 17:50, Joachim Breitner wrote: > Hi, > > Am Sonntag, den 03.02.2019, 10:45 -0500 schrieb Eric Seidel: > > I'm more bothered by the fact that the data/constructor tag has now > > become 'pattern', which feels to me like it should only apply to > > pattern synonyms. But according to > > https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-425736470 > > it sounds like that ship may have sailed already if we want to be > > consistent (which we should!). > > We can maybe fix it consistently, and phase out “pattern” (make it an > alias for whatever we choose) … but do we have an obviously appropriate > name? > > Cheers, > Joachim > > -- > 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 > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature) From marlowsd at gmail.com Mon Feb 4 08:44:43 2019 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 4 Feb 2019 08:44:43 +0000 Subject: [ghc-steering-committee] Proposal #167 (Deprecated Entities): Request for comments In-Reply-To: <1549247955.1943852.1650103480.0C9B42AD@webmail.messagingengine.com> References: <3e75b2a8940c0e4faa0736ba207749ea577088eb.camel@joachim-breitner.de> <1549208744.1789639.1649829992.5A1CCE2B@webmail.messagingengine.com> <2f4721f409d074f753d5c8d439f946ca9a0a4cbe.camel@joachim-breitner.de> <1549247955.1943852.1650103480.0C9B42AD@webmail.messagingengine.com> Message-ID: The point of "pattern" (I believe) is that we want it to be invisible to the importer whether a constructor name was declared as a pattern synonym or a real data constructor, to allow abstraction and smooth migration of APIs when the concrete representation of a datatype changes. However, it would also make sense to allow "data" instead of "pattern", with exactly the same meaning (import either a data constructor or a pattern synonym with the given name). I wonder why we didn't do that. On this proposal, I think the named, standalone variant is preferable to the positional variant if we choose only one, because it allows more flexibility. Although I could imagine both being useful. Cheers Simon On Mon, 4 Feb 2019 at 02:39, Eric Seidel wrote: > In > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst > we already have an approved alternative: "value". > > On Sun, Feb 3, 2019, at 17:50, Joachim Breitner wrote: > > Hi, > > > > Am Sonntag, den 03.02.2019, 10:45 -0500 schrieb Eric Seidel: > > > I'm more bothered by the fact that the data/constructor tag has now > > > become 'pattern', which feels to me like it should only apply to > > > pattern synonyms. But according to > > > > https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-425736470 > > > it sounds like that ship may have sailed already if we want to be > > > consistent (which we should!). > > > > We can maybe fix it consistently, and phase out “pattern” (make it an > > alias for whatever we choose) … but do we have an obviously appropriate > > name? > > > > Cheers, > > Joachim > > > > -- > > 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 > > Email had 1 attachment: > > + signature.asc > > 1k (application/pgp-signature) > _______________________________________________ > 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 Mon Feb 4 22:20:33 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 04 Feb 2019 23:20:33 +0100 Subject: [ghc-steering-committee] Proposal #167 (Deprecated Entities): Request for comments In-Reply-To: References: <3e75b2a8940c0e4faa0736ba207749ea577088eb.camel@joachim-breitner.de> <1549208744.1789639.1649829992.5A1CCE2B@webmail.messagingengine.com> <2f4721f409d074f753d5c8d439f946ca9a0a4cbe.camel@joachim-breitner.de> <1549247955.1943852.1650103480.0C9B42AD@webmail.messagingengine.com> Message-ID: Hi, Am Montag, den 04.02.2019, 08:44 +0000 schrieb Simon Marlow: > The point of "pattern" (I believe) is that we want it to be invisible > to the importer whether a constructor name was declared as a pattern > synonym or a real data constructor, to allow abstraction and smooth > migration of APIs when the concrete representation of a datatype > changes. However, it would also make sense to allow "data" instead of > "pattern", with exactly the same meaning (import either a data > constructor or a pattern synonym with the given name). I wonder why > we didn't do that. I agree that “the better name” should be a synonym for pattern (or the other way around). But I don’t think it should be data, because we write data Bool = True | False and it would be odd if `data Bool` means something different here and in an import statement. “value”, as Eric says, is better. Cheers, 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 Feb 4 22:46:20 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 04 Feb 2019 23:46:20 +0100 Subject: [ghc-steering-committee] Please review #193: forall keyword, Shepherd: Eric Message-ID: <669a5334099c20ee445f0883c370320b9e9a65cb.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: make `forall` a keyword proposed by Richard: https://github.com/ghc-proposals/ghc-proposals/pull/193 https://github.com/goldfirere/ghc-proposals/blob/forall-keyword/proposals/0000-forall-keyword.rst I propose Eris Seidel as the shepherd. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, 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 rae at cs.brynmawr.edu Tue Feb 5 16:21:44 2019 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 5 Feb 2019 11:21:44 -0500 Subject: [ghc-steering-committee] Proposal #167 (Deprecated Entities): Request for comments In-Reply-To: References: <3e75b2a8940c0e4faa0736ba207749ea577088eb.camel@joachim-breitner.de> <1549208744.1789639.1649829992.5A1CCE2B@webmail.messagingengine.com> <2f4721f409d074f753d5c8d439f946ca9a0a4cbe.camel@joachim-breitner.de> <1549247955.1943852.1650103480.0C9B42AD@webmail.messagingengine.com> Message-ID: - In general, I favor the named variant, as it's easier (i.e. more flexible) to work with. Of course, we need to be positional to deprecate instances (though this is not in the proposal, so is the idea in scope here?). - Though I understand the reasons against it, I'm an unabashed supporter of using the word "data" to supplant "pattern". My principal argument is that `data` can be used freely in the syntax, given that it's a keyword that has current meaning only as the first lexeme in a top-level declaration. (Specifically, I pine for a future where types and terms mix. We can then use `type` and `data` in the middle of expressions/types to denote namespaces.) It also works nicely to mean "data constructor". I agree that it doesn't work as well with functions or the potential confusion around "data Bool = True | False" (though, in that last example, we can pretend hard that the `data` applies only to the bits after the `=`). The problem with `value` is that we would have `{-# DEPRECATED value, foo #-}` mean something very different than `{-# DEPRECATED value foo #-}`. This isn't a deal-breaker (punctuation normally is important in programming), but it's unfortunate. - Extending the proposal slightly, I would love to see a warning if one deprecation (or fixity declaration, while we're at it) applies to both a term-level entity and a type-level one (without specifying both separately). In my opinion, the fact that we ever allowed that is embarrassing. :) In the future, we might even say that it's an error. Richard > On Feb 4, 2019, at 5:20 PM, Joachim Breitner wrote: > > Hi, > > Am Montag, den 04.02.2019, 08:44 +0000 schrieb Simon Marlow: >> The point of "pattern" (I believe) is that we want it to be invisible >> to the importer whether a constructor name was declared as a pattern >> synonym or a real data constructor, to allow abstraction and smooth >> migration of APIs when the concrete representation of a datatype >> changes. However, it would also make sense to allow "data" instead of >> "pattern", with exactly the same meaning (import either a data >> constructor or a pattern synonym with the given name). I wonder why >> we didn't do that. > > I agree that “the better name” should be a synonym for pattern (or the > other way around). > > But I don’t think it should be data, because we write > > data Bool = True | False > > and it would be odd if `data Bool` means something different here and > in an import statement. > > “value”, as Eric says, is better. > > Cheers, > Joachim > -- > 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 From mail at joachim-breitner.de Tue Feb 5 22:03:20 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 05 Feb 2019 23:03:20 +0100 Subject: [ghc-steering-committee] Please review #155: Type Variable in Lambdas, Shepherd: Iavor Message-ID: <7744c660c506b44bcd9c20f92a6c8de030d64206.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: Richard wants to bind Type variables in lambda.: https://github.com/ghc-proposals/ghc-proposals/pull/155 https://github.com/goldfirere/ghc-proposals/blob/type-lambda/proposals/0000-type-lambda.rst I propose Iavor Diatchki the shepherd. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, 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 eric at seidel.io Wed Feb 6 00:11:48 2019 From: eric at seidel.io (Eric Seidel) Date: Tue, 05 Feb 2019 19:11:48 -0500 Subject: [ghc-steering-committee] Proposal #167 (Deprecated Entities): Request for comments In-Reply-To: References: <3e75b2a8940c0e4faa0736ba207749ea577088eb.camel@joachim-breitner.de> <1549208744.1789639.1649829992.5A1CCE2B@webmail.messagingengine.com> <2f4721f409d074f753d5c8d439f946ca9a0a4cbe.camel@joachim-breitner.de> <1549247955.1943852.1650103480.0C9B42AD@webmail.messagingengine.com> Message-ID: <1549411908.1798458.1651700224.6F169D98@webmail.messagingengine.com> Simon M says: > On this proposal, I think the named, standalone variant is preferable to the positional variant if we choose only one, because it allows more flexibility. Although I could imagine both being useful. Indeed, I'd be perfectly happy to have both variants. (And we could extend this to existing deprecations/warnings, e.g. there's no good reason to force module deprecations to be positional.) Richard says: > - Though I understand the reasons against it, I'm an unabashed supporter > of using the word "data" to supplant "pattern". My principal argument is > that `data` can be used freely in the syntax, given that it's a keyword > that has current meaning only as the first lexeme in a top-level > declaration. (Specifically, I pine for a future where types and terms > mix. We can then use `type` and `data` in the middle of expressions/ > types to denote namespaces.) It also works nicely to mean "data > constructor". I agree that it doesn't work as well with functions or the > potential confusion around "data Bool = True | False" (though, in that > last example, we can pretend hard that the `data` applies only to the > bits after the `=`). The problem with `value` is that we would have `{-# > DEPRECATED value, foo #-}` mean something very different than `{-# > DEPRECATED value foo #-}`. This isn't a deal-breaker (punctuation > normally is important in programming), but it's unfortunate. I don't have a problem with `data`. I think the potential confusion around `data Bool = True | False` won't faze experienced Haskellers (who are the target audience for these pragmas). And the fact that `data` is already a reserved keyword is quite nice. My main concern is that I'd like us to be consistent in how we disambiguate namespaces. If we want to use `data`, we should use it everywhere (synonyms are fine by me as long as they are also consistent). This would means we'd need to revise the fixity proposal I linked to above. From eric at seidel.io Wed Feb 6 00:50:56 2019 From: eric at seidel.io (Eric Seidel) Date: Tue, 05 Feb 2019 19:50:56 -0500 Subject: [ghc-steering-committee] [Proposal] #193: Make `forall` a keyword in type (recommendation: accept) Message-ID: <1549414256.1846791.1651722392.573766F2@webmail.messagingengine.com> This proposal suggests making `forall` a keyword at the type-level. `forall` is currently only a keyword when `-XExplicitForAll` is enabled. This change would avoid a potentially confusing situation where the meaning of a type can change based on which extensions are enabled. For example, ``` f2 :: forall a -> a -> a ``` with no extensions, the `forall a` would be interpreted as two regular type variables. But if we enable the upcoming "visible dependent quantification" extension (I assume there's an extension involved here somewhere, the proposal doesn't say), the `forall a` would be interpreted as a *single* dependently quantified type variable `a`. The only concerns are that this change could break existing programs, and that it moves us further away from the standard. I'd be very suspicious of any programs that used `forall` as a type variable, as that's just ripe for confusion. And it's a very small step away from the standard, so I don't think that should stand in the proposal's way either. I recommend we accept the proposal. From iavor.diatchki at gmail.com Wed Feb 6 01:03:39 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 5 Feb 2019 17:03:39 -0800 Subject: [ghc-steering-committee] [Proposal] #193: Make `forall` a keyword in type (recommendation: accept) In-Reply-To: <1549414256.1846791.1651722392.573766F2@webmail.messagingengine.com> References: <1549414256.1846791.1651722392.573766F2@webmail.messagingengine.com> Message-ID: Agreed that `forall` should be a keyword in types. I didn't realize it wasn't already :) On Tue, Feb 5, 2019 at 4:51 PM Eric Seidel wrote: > This proposal suggests making `forall` a keyword at the type-level. > `forall` is currently only a keyword when `-XExplicitForAll` is enabled. > > This change would avoid a potentially confusing situation where the > meaning of a type can change based on which extensions are enabled. For > example, > > ``` > f2 :: forall a -> a -> a > ``` > > with no extensions, the `forall a` would be interpreted as two regular > type variables. But if we enable the upcoming "visible dependent > quantification" extension (I assume there's an extension involved here > somewhere, the proposal doesn't say), the `forall a` would be interpreted > as a *single* dependently quantified type variable `a`. > > The only concerns are that this change could break existing programs, and > that it moves us further away from the standard. I'd be very suspicious of > any programs that used `forall` as a type variable, as that's just ripe for > confusion. And it's a very small step away from the standard, so I don't > think that should stand in the proposal's way either. > > I recommend we accept the proposal. > > _______________________________________________ > 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 Wed Feb 6 02:14:12 2019 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 5 Feb 2019 21:14:12 -0500 Subject: [ghc-steering-committee] Proposal #167 (Deprecated Entities): Request for comments In-Reply-To: <1549411908.1798458.1651700224.6F169D98@webmail.messagingengine.com> References: <3e75b2a8940c0e4faa0736ba207749ea577088eb.camel@joachim-breitner.de> <1549208744.1789639.1649829992.5A1CCE2B@webmail.messagingengine.com> <2f4721f409d074f753d5c8d439f946ca9a0a4cbe.camel@joachim-breitner.de> <1549247955.1943852.1650103480.0C9B42AD@webmail.messagingengine.com> <1549411908.1798458.1651700224.6F169D98@webmail.messagingengine.com> Message-ID: > On Feb 5, 2019, at 7:11 PM, Eric Seidel wrote: > > My main concern is that I'd like us to be consistent in how we disambiguate namespaces. If we want to use `data`, we should use it everywhere (synonyms are fine by me as long as they are also consistent). This would means we'd need to revise the fixity proposal I linked to above. Yes, I should have included this in my email. If we decide to go in this direction, I would want to be consistent. This would include updating the fixity proposal (which is, I believe, still unimplemented) and expanding -XExplicitNamespaces to include `data`. Eventually, we would deprecate the use of `pattern` in import/export lists and then remove that feature. I suppose all this would necessitate yet another proposal.... but I do think the wider community (not just this list) should weigh in. However, before doing so, I'd be curious for more feedback from this group as a test-bed. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Wed Feb 6 08:35:45 2019 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 6 Feb 2019 08:35:45 +0000 Subject: [ghc-steering-committee] #176: SCC Parsing, recommendation: accept In-Reply-To: <60a52ca934167ab68ecab76bde5789f74e242181.camel@joachim-breitner.de> References: <60a52ca934167ab68ecab76bde5789f74e242181.camel@joachim-breitner.de> Message-ID: Proposal #176 is a small change to the syntax to make the parsing of certain pragmas (SCC, GENERATED, CORE) more principled and less likely to lead to confusion for users. The proposal itself has a nice motivation section that explains the problem ( https://github.com/int-index/ghc-proposals/blob/scc-parsing/proposals/0000-scc-parsing.rst) but if that's too long then the summary is to adopt these principles: 1. Annotations have the lowest precedence of all syntactic constructs. 2. Adding an annotation does not affect the structure or meaning of an expression in ways other than adding an annotation to a subexpression. and it turns out that doing that means that there are places where an SCC annotation should be illegal. Some of those places were illegal already, but not all - some places were SCC is currently legal have the effect of violating principle (2) above. The change itself is to move a few productions in the grammar, making SCC annotations have the same precedence and associativity as the family of constructs including lambda, let, and do. That is, they have the lowest precedence and are right-associative, which is what we normally expect (the informal description is usually "extends as far to the right as possible"). A lot of the discussion has been around how to precisely specify and document the rule for users, and I'm satisfied that we can do this. The only reason not to accept this would be that some existing code may fail to compile with the new grammar. However, it's likely to be rare and easy to fix, and within the bounds of the kinds of breaking change that we normally make in a major GHC release. Furthermore fixing the code to work with both old and new compilers doesn't require any conditional compilation. So, I propose we accept this. Cheers, Simon On Sun, 3 Feb 2019 at 22:48, Joachim Breitner wrote: > Dear Committee, > > this is your secretary speaking: > > Meaning-preserving parsing rules for SCC annotations > has been proposed by Vladislav Zavialov: > https://github.com/ghc-proposals/ghc-proposals/pull/176 > > https://github.com/int-index/ghc-proposals/blob/scc-parsing/proposals/0000-scc-parsing.rst > > I propose Simon Marlow as the shepherd (he already glimpsed at it, so > hopefully already has an opinion.) > > Please reach consensus as described in > https://github.com/ghc-proposals/ghc-proposals#committee-process > I suggest you make a recommendation, in a new e-mail thread with the > proposal number in the subject, 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/ > > _______________________________________________ > 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 Feb 6 10:52:41 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 6 Feb 2019 10:52:41 +0000 Subject: [ghc-steering-committee] [Proposal] #193: Make `forall` a keyword in type (recommendation: accept) In-Reply-To: <1549414256.1846791.1651722392.573766F2@webmail.messagingengine.com> References: <1549414256.1846791.1651722392.573766F2@webmail.messagingengine.com> Message-ID: I'm supportive. Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Eric Seidel | Sent: 06 February 2019 00:51 | To: ghc-steering-committee at haskell.org | Subject: [ghc-steering-committee] [Proposal] #193: Make `forall` a keyword | in type (recommendation: accept) | | This proposal suggests making `forall` a keyword at the type-level. | `forall` is currently only a keyword when `-XExplicitForAll` is enabled. | | This change would avoid a potentially confusing situation where the meaning | of a type can change based on which extensions are enabled. For example, | | ``` | f2 :: forall a -> a -> a | ``` | | with no extensions, the `forall a` would be interpreted as two regular type | variables. But if we enable the upcoming "visible dependent quantification" | extension (I assume there's an extension involved here somewhere, the | proposal doesn't say), the `forall a` would be interpreted as a *single* | dependently quantified type variable `a`. | | The only concerns are that this change could break existing programs, and | that it moves us further away from the standard. I'd be very suspicious of | any programs that used `forall` as a type variable, as that's just ripe for | confusion. And it's a very small step away from the standard, so I don't | think that should stand in the proposal's way either. | | I recommend we accept the proposal. | | _______________________________________________ | 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 Wed Feb 6 15:47:51 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 6 Feb 2019 15:47:51 +0000 Subject: [ghc-steering-committee] #176: SCC Parsing, recommendation: accept In-Reply-To: References: <60a52ca934167ab68ecab76bde5789f74e242181.camel@joachim-breitner.de> Message-ID: I’m supportive. Simon From: ghc-steering-committee On Behalf Of Simon Marlow Sent: 06 February 2019 08:36 To: Joachim Breitner Cc: ghc-steering-committee at haskell.org Subject: [ghc-steering-committee] #176: SCC Parsing, recommendation: accept Proposal #176 is a small change to the syntax to make the parsing of certain pragmas (SCC, GENERATED, CORE) more principled and less likely to lead to confusion for users. The proposal itself has a nice motivation section that explains the problem (https://github.com/int-index/ghc-proposals/blob/scc-parsing/proposals/0000-scc-parsing.rst) but if that's too long then the summary is to adopt these principles: 1. Annotations have the lowest precedence of all syntactic constructs. 2. Adding an annotation does not affect the structure or meaning of an expression in ways other than adding an annotation to a subexpression. and it turns out that doing that means that there are places where an SCC annotation should be illegal. Some of those places were illegal already, but not all - some places were SCC is currently legal have the effect of violating principle (2) above. The change itself is to move a few productions in the grammar, making SCC annotations have the same precedence and associativity as the family of constructs including lambda, let, and do. That is, they have the lowest precedence and are right-associative, which is what we normally expect (the informal description is usually "extends as far to the right as possible"). A lot of the discussion has been around how to precisely specify and document the rule for users, and I'm satisfied that we can do this. The only reason not to accept this would be that some existing code may fail to compile with the new grammar. However, it's likely to be rare and easy to fix, and within the bounds of the kinds of breaking change that we normally make in a major GHC release. Furthermore fixing the code to work with both old and new compilers doesn't require any conditional compilation. So, I propose we accept this. Cheers, Simon On Sun, 3 Feb 2019 at 22:48, Joachim Breitner > wrote: Dear Committee, this is your secretary speaking: Meaning-preserving parsing rules for SCC annotations has been proposed by Vladislav Zavialov: https://github.com/ghc-proposals/ghc-proposals/pull/176 https://github.com/int-index/ghc-proposals/blob/scc-parsing/proposals/0000-scc-parsing.rst I propose Simon Marlow as the shepherd (he already glimpsed at it, so hopefully already has an opinion.) Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, 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/ _______________________________________________ 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 Wed Feb 6 16:17:01 2019 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Wed, 6 Feb 2019 11:17:01 -0500 Subject: [ghc-steering-committee] #176: SCC Parsing, recommendation: accept In-Reply-To: References: <60a52ca934167ab68ecab76bde5789f74e242181.camel@joachim-breitner.de> Message-ID: <4D963B1C-B7FE-4C3B-84B0-08DC1B606C92@cs.brynmawr.edu> Thanks for the great summary, Simon M. Overall, this seems like a simplification. I vote "yes". Richard > On Feb 6, 2019, at 10:47 AM, Simon Peyton Jones via ghc-steering-committee wrote: > > I’m supportive. > > Simon > > From: ghc-steering-committee On Behalf Of Simon Marlow > Sent: 06 February 2019 08:36 > To: Joachim Breitner > Cc: ghc-steering-committee at haskell.org > Subject: [ghc-steering-committee] #176: SCC Parsing, recommendation: accept > > Proposal #176 is a small change to the syntax to make the parsing of certain pragmas (SCC, GENERATED, CORE) more principled and less likely to lead to confusion for users. The proposal itself has a nice motivation section that explains the problem (https://github.com/int-index/ghc-proposals/blob/scc-parsing/proposals/0000-scc-parsing.rst ) but if that's too long then the summary is to adopt these principles: > > Annotations have the lowest precedence of all syntactic constructs. > Adding an annotation does not affect the structure or meaning of an expression in ways other than adding an annotation to a subexpression. > and it turns out that doing that means that there are places where an SCC annotation should be illegal. Some of those places were illegal already, but not all - some places were SCC is currently legal have the effect of violating principle (2) above. > > The change itself is to move a few productions in the grammar, making SCC annotations have the same precedence and associativity as the family of constructs including lambda, let, and do. That is, they have the lowest precedence and are right-associative, which is what we normally expect (the informal description is usually "extends as far to the right as possible"). > > A lot of the discussion has been around how to precisely specify and document the rule for users, and I'm satisfied that we can do this. > > The only reason not to accept this would be that some existing code may fail to compile with the new grammar. However, it's likely to be rare and easy to fix, and within the bounds of the kinds of breaking change that we normally make in a major GHC release. Furthermore fixing the code to work with both old and new compilers doesn't require any conditional compilation. > > So, I propose we accept this. > > Cheers, > Simon > > > On Sun, 3 Feb 2019 at 22:48, Joachim Breitner > wrote: > Dear Committee, > > this is your secretary speaking: > > Meaning-preserving parsing rules for SCC annotations > has been proposed by Vladislav Zavialov: > https://github.com/ghc-proposals/ghc-proposals/pull/176 > https://github.com/int-index/ghc-proposals/blob/scc-parsing/proposals/0000-scc-parsing.rst > > I propose Simon Marlow as the shepherd (he already glimpsed at it, so > hopefully already has an opinion.) > > Please reach consensus as described in > https://github.com/ghc-proposals/ghc-proposals#committee-process > I suggest you make a recommendation, in a new e-mail thread with the > proposal number in the subject, 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/ > > _______________________________________________ > 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 Wed Feb 6 16:40:14 2019 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Wed, 6 Feb 2019 17:40:14 +0100 Subject: [ghc-steering-committee] #176: SCC Parsing, recommendation: accept In-Reply-To: References: <60a52ca934167ab68ecab76bde5789f74e242181.camel@joachim-breitner.de> Message-ID: <9DF44620-49DF-4D85-B6D1-0D447B035A58@justtesting.org> +1 > Am 06.02.2019 um 09:35 schrieb Simon Marlow : > > Proposal #176 is a small change to the syntax to make the parsing of certain pragmas (SCC, GENERATED, CORE) more principled and less likely to lead to confusion for users. The proposal itself has a nice motivation section that explains the problem (https://github.com/int-index/ghc-proposals/blob/scc-parsing/proposals/0000-scc-parsing.rst ) but if that's too long then the summary is to adopt these principles: > Annotations have the lowest precedence of all syntactic constructs. > Adding an annotation does not affect the structure or meaning of an expression in ways other than adding an annotation to a subexpression. > and it turns out that doing that means that there are places where an SCC annotation should be illegal. Some of those places were illegal already, but not all - some places were SCC is currently legal have the effect of violating principle (2) above. > > The change itself is to move a few productions in the grammar, making SCC annotations have the same precedence and associativity as the family of constructs including lambda, let, and do. That is, they have the lowest precedence and are right-associative, which is what we normally expect (the informal description is usually "extends as far to the right as possible"). > > A lot of the discussion has been around how to precisely specify and document the rule for users, and I'm satisfied that we can do this. > > The only reason not to accept this would be that some existing code may fail to compile with the new grammar. However, it's likely to be rare and easy to fix, and within the bounds of the kinds of breaking change that we normally make in a major GHC release. Furthermore fixing the code to work with both old and new compilers doesn't require any conditional compilation. > > So, I propose we accept this. > > Cheers, > Simon > > > On Sun, 3 Feb 2019 at 22:48, Joachim Breitner > wrote: > Dear Committee, > > this is your secretary speaking: > > Meaning-preserving parsing rules for SCC annotations > has been proposed by Vladislav Zavialov: > https://github.com/ghc-proposals/ghc-proposals/pull/176 > https://github.com/int-index/ghc-proposals/blob/scc-parsing/proposals/0000-scc-parsing.rst > > I propose Simon Marlow as the shepherd (he already glimpsed at it, so > hopefully already has an opinion.) > > Please reach consensus as described in > https://github.com/ghc-proposals/ghc-proposals#committee-process > I suggest you make a recommendation, in a new e-mail thread with the > proposal number in the subject, 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/ > > _______________________________________________ > 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 marlowsd at gmail.com Fri Feb 8 08:56:43 2019 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 8 Feb 2019 08:56:43 +0000 Subject: [ghc-steering-committee] Proposal #167 (Deprecated Entities): Request for comments In-Reply-To: References: <3e75b2a8940c0e4faa0736ba207749ea577088eb.camel@joachim-breitner.de> <1549208744.1789639.1649829992.5A1CCE2B@webmail.messagingengine.com> <2f4721f409d074f753d5c8d439f946ca9a0a4cbe.camel@joachim-breitner.de> <1549247955.1943852.1650103480.0C9B42AD@webmail.messagingengine.com> <1549411908.1798458.1651700224.6F169D98@webmail.messagingengine.com> Message-ID: On Wed, 6 Feb 2019 at 02:14, Richard Eisenberg wrote: > > On Feb 5, 2019, at 7:11 PM, Eric Seidel wrote: > > My main concern is that I'd like us to be consistent in how we > disambiguate namespaces. If we want to use `data`, we should use it > everywhere (synonyms are fine by me as long as they are also consistent). > This would means we'd need to revise the fixity proposal I linked to above. > > > > Yes, I should have included this in my email. If we decide to go in this > direction, I would want to be consistent. This would include updating the > fixity proposal (which is, I believe, still unimplemented) and expanding > -XExplicitNamespaces to include `data`. Eventually, we would deprecate the > use of `pattern` in import/export lists and then remove that feature. I > suppose all this would necessitate yet another proposal.... but I do think > the wider community (not just this list) should weigh in. However, before > doing so, I'd be curious for more feedback from this group as a test-bed. > I'm in favour of that. Joachim's point about the potential confusion with "data Bool = ..." is valid, but I think on balance using "data" is less confusing than the alternatives. Cheers Simon > > 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 rae at cs.brynmawr.edu Mon Feb 11 21:20:13 2019 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 11 Feb 2019 16:20:13 -0500 Subject: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped (recommendation: accept) In-Reply-To: References: <87zhunv09p.fsf@smart-cactus.org> <828C422B-7CFB-45A0-96DD-66C14AC3A2E1@cs.brynmawr.edu> <592230B0-33F9-468F-8676-F6DED97E49CE@seidel.io> <1545190628.935552.1613138120.0DE606A9@webmail.messagingengine.com> <1545216599.1040104.1613362848.19A543DA@webmail.messagingengine.com> <5152A0BE-E7B9-489A-A7C7-8C5BCAE01E0C@cs.brynmawr.edu> <1547917186.2586273.1638789112.522284A4@webmail.messagingengine.com> Message-ID: <9868312E-68E9-4EC9-873A-D6F6154FD67C@cs.brynmawr.edu> I see that you've posted acceptance, Ben. Thanks. But my understanding is that the accepted version was the one without `lift` in the class. Is that your understanding, too? If so, would you mind posting to the proposal author? (I think it's cleaner to have communication on this come from the shepherd.) Thanks! Richard > On Jan 30, 2019, at 8:09 AM, Simon Peyton Jones via ghc-steering-committee wrote: > > I'm content with liftTyped. And while (2) is nicer ab-initio, it's not a big deal having two members of the class, so I'm fine with (1). > > Simon > > | -----Original Message----- > | From: ghc-steering-committee > | On Behalf Of Eric Seidel > | Sent: 19 January 2019 17:00 > | To: ghc-steering-committee at haskell.org > | Subject: Re: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped > | (recommendation: accept) > | > | Let's try to pick this discussion back up. The proposal has been > | lingering on our end for a couple months now! > | > | We all seem to be in agreement that the basic proposal of adding > | `liftTyped` should be accepted. The discussion has mostly focused on > | backwards-compatibility concerns around the default implementation of > | `Lift`, specifically that the new mutually-recursive definitions of > | `lift` and `liftTyped` could break **clients** of libraries that use TH > | without even issuing a warning in the libraries themselves. > | > | There are two proposed solutions that seem to have some support. > | > | 1. I suggested a targeted warning/error about empty `Lift` instances that > | could be bundled with GHC. TH is bundled with GHC, so this would > | guarantee that we notify (or break) libraries before client code is > | affected. It would also let library authors avoid CPP while supporting > | multiple versions of TH. Joachim expressed his support for this solution. > | > | 2. The proposal suggests an alternative that replaces `lift` with > | `liftTyped` as the sole method of `Lift`. This is probably how we would > | design the `Lift` class today if we were starting from scratch. On the > | other hand, it forces library authors to use CPP to support multiple > | versions of TH, which people often try to avoid (e.g. due to tooling > | issues). Simon and Richard have expressed support for this solution. > | > | I would actually be happy with either solution. > | > | Joachim, are you happy with option 2? If so, perhaps we should just agree > | on it and move forward with the proposal. > | > | On Fri, Dec 21, 2018, at 22:04, Richard Eisenberg wrote: > | > I favor Simon's suggestion. Just rip out `lift` from the class and > | > define it as a top-level function. This breaks backward-compat, but in > | > an inescapable way. And TH users are accustomed to breakage. My > | > problem earlier wasn't just that it wasn't backward-compatible, but > | > that it was incompatible in such a terrible way. Simon's suggestion > | > leads to a better incompatibility. > | > > | > Richard > | > > | > > On Dec 19, 2018, at 5:49 AM, Eric Seidel wrote: > | > > > | > > Joachim wrote: > | > >> I think 1. is at odds in GHC – we allow partiality in other places > | > >> as well (partially initialized records, for example). Disallowing > | > >> it feels like a too fundamental change to the language for the > | > >> problem we need to solve here. > | > > > | > > Yes, I agree that changing the semantics of MINIMAL solely to fix > | this issue is not a great idea. But having a MINIMAL violation be a > | warning instead of an error generally feels shady to me. > | > > > | > > The only use of MINIMAL pragmas I've seen is to break mutually > | recursive definitions. That means there's an important difference between > | MINIMAL pragmas and other sources of partiality. In a partial record > | construction, your program will be fine so long as you don't access the > | uninitialized fields. This is dangerous, so we warn you about it, but > | it's still possible that your program will be correct. With a MINIMAL > | violation, it seems like the programmer is telling us that an instance > | *cannot* be correct unless it provides the minimal definitions. > | > > > | > > But I shouldn't derail the conversation.. Perhaps I'll write up a > | separate proposal about MINIMAL. > | > > > | > >> 3. is a neat idea, but again a very big cannon for a niche problem. > | > >> If we _had_ ghc-fix, then this might be a good approach, and we can > | > >> keep this in mind as additional evidence that ghc-fix would be good > | > >> (GSOC anyone), but let's not wait for that here. > | > > > | > > Indeed, I wouldn't make this wait on ghc-fix either, but it would be > | a very nice thing to have right now! > | > > > | > >> 2. is good, I think. We have had plenty of such kludges, e.g. > | > >> around the Monad refactoring. > | > > > | > > If we're ok with kludges like this to ease the migration, I think > | it's clearly the simplest solution. > | > > > | > > --- > | > > > | > > Simon wrote: > | > > > | > >> Is there any reason for not adopting the second alternative in > | section 5: make liftTyped the sole method of Lift? > | > > > | > > I suspect this would break more code than the current proposal, since > | you do sometimes have to write a manual `lift` instance (eg if you have a > | field like Text that doesn't have an instance). Fixing such code would > | also require CPP, which we usually try to avoid. > | > > _______________________________________________ > | > > ghc-steering-committee mailing list > | > > ghc-steering-committee at haskell.org > | > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-commi > | > > ttee > | > > | _______________________________________________ > | 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 simonpj at microsoft.com Thu Feb 14 17:54:00 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 14 Feb 2019 17:54:00 +0000 Subject: [ghc-steering-committee] [Proposal] #193: Make `forall` a keyword in type (recommendation: accept) In-Reply-To: References: <1549414256.1846791.1651722392.573766F2@webmail.messagingengine.com> Message-ID: Shall we conclude on this? Vlad has implemented it: https://gitlab.haskell.org/ghc/ghc/merge_requests/363 Simon From: ghc-steering-committee On Behalf Of Iavor Diatchki Sent: 06 February 2019 01:04 To: Eric Seidel Cc: ghc-steering-committee Subject: Re: [ghc-steering-committee] [Proposal] #193: Make `forall` a keyword in type (recommendation: accept) Agreed that `forall` should be a keyword in types. I didn't realize it wasn't already :) On Tue, Feb 5, 2019 at 4:51 PM Eric Seidel > wrote: This proposal suggests making `forall` a keyword at the type-level. `forall` is currently only a keyword when `-XExplicitForAll` is enabled. This change would avoid a potentially confusing situation where the meaning of a type can change based on which extensions are enabled. For example, ``` f2 :: forall a -> a -> a ``` with no extensions, the `forall a` would be interpreted as two regular type variables. But if we enable the upcoming "visible dependent quantification" extension (I assume there's an extension involved here somewhere, the proposal doesn't say), the `forall a` would be interpreted as a *single* dependently quantified type variable `a`. The only concerns are that this change could break existing programs, and that it moves us further away from the standard. I'd be very suspicious of any programs that used `forall` as a type variable, as that's just ripe for confusion. And it's a very small step away from the standard, so I don't think that should stand in the proposal's way either. I recommend we accept the proposal. _______________________________________________ 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 eric at seidel.io Thu Feb 14 18:22:03 2019 From: eric at seidel.io (Eric Seidel) Date: Thu, 14 Feb 2019 13:22:03 -0500 Subject: [ghc-steering-committee] [Proposal] #193: Make `forall` a keyword in type (recommendation: accept) In-Reply-To: References: <1549414256.1846791.1651722392.573766F2@webmail.messagingengine.com> Message-ID: <1550168523.3331425.1658105232.68B83788@webmail.messagingengine.com> Yep, it's been at least a week and the feedback has been all positive. I'll mark the proposal accepted. On Thu, Feb 14, 2019, at 12:54, Simon Peyton Jones wrote: > Shall we conclude on this? Vlad has implemented it: > https://gitlab.haskell.org/ghc/ghc/merge_requests/363 > > Simon > > From: ghc-steering-committee bounces at haskell.org> On Behalf Of Iavor Diatchki > Sent: 06 February 2019 01:04 > To: Eric Seidel > Cc: ghc-steering-committee > Subject: Re: [ghc-steering-committee] [Proposal] #193: Make `forall` a > keyword in type (recommendation: accept) > > Agreed that `forall` should be a keyword in types. I didn't realize it > wasn't already :) > > On Tue, Feb 5, 2019 at 4:51 PM Eric Seidel > > wrote: > This proposal suggests making `forall` a keyword at the type-level. > `forall` is currently only a keyword when `-XExplicitForAll` is enabled. > > This change would avoid a potentially confusing situation where the > meaning of a type can change based on which extensions are enabled. For > example, > > ``` > f2 :: forall a -> a -> a > ``` > > with no extensions, the `forall a` would be interpreted as two regular > type variables. But if we enable the upcoming "visible dependent > quantification" extension (I assume there's an extension involved here > somewhere, the proposal doesn't say), the `forall a` would be > interpreted as a *single* dependently quantified type variable `a`. > > The only concerns are that this change could break existing programs, > and that it moves us further away from the standard. I'd be very > suspicious of any programs that used `forall` as a type variable, as > that's just ripe for confusion. And it's a very small step away from the > standard, so I don't think that should stand in the proposal's way > either. > > I recommend we accept the proposal. > > _______________________________________________ > 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 Tue Feb 19 18:28:36 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 19 Feb 2019 10:28:36 -0800 Subject: [ghc-steering-committee] Discussion on #155 Type Variable in Labmdas Message-ID: Hello, let's get the discussion going about proposal #155 ( https://github.com/goldfirere/ghc-proposals/blob/type-lambda/proposals/0000-type-lambda.rst ). Summary: the idea is pretty simple: allow functions to name their type arguments explicitly, so that they can be used in type signatures within the function's definition. The notation for a type argument is `@a`, and such type arguments can be used only when functions have an explicit type signature (technically, when GHC is doing "checking" rather then "inference"). This proposal provides an alternative to "ScopedTypeVariables" to refer to type parameters, which I think is a step in the right direction, as using the `forall` to introduce type variables always felt a bit hacky to me (now, there's a technical argument :) I am a bit concerned with the notation though: in other places where we use `@a`, (e.g., #126 type application in patterns, and TypeApplications) the `a` is a type, while in this use it must be a variable. I wonder if this punning might be confusing. I don't really have an alternative suggestion though. What does everyone else thing? -Iavor -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Feb 19 18:49:48 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 19 Feb 2019 14:49:48 -0400 Subject: [ghc-steering-committee] Discussion on #155 Type Variable in Lambdas In-Reply-To: References: Message-ID: <4a657133c842a6a478dc4ceb916a45ec44eb12ad.camel@joachim-breitner.de> Hi, Am Dienstag, den 19.02.2019, 10:28 -0800 schrieb Iavor Diatchki: > I am a bit concerned with the notation though: in other places where > we use `@a`, (e.g., #126 type application in patterns, and > TypeApplications) the `a` is a type, while in this use it must be a > variable. I wonder if this punning might be confusing. I don't > really have an alternative suggestion though. on the term level, lambda parameters are variables and function arguments are terms, without a different syntax here. So I think that is fine. Ok, there is a bit of syntactic sugar to allow patterns in lambdas. So maybe a future proposal can extend this to allow type patterns in lambdas… But I think I am fine doing small steps here. Cheers, 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 iavor.diatchki at gmail.com Tue Feb 19 19:01:12 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 19 Feb 2019 11:01:12 -0800 Subject: [ghc-steering-committee] Discussion on #155 Type Variable in Labmdas In-Reply-To: References: Message-ID: After a bit more thought, I am not sure what do we get with this notation over ScopedTypeVariables. In particular, here are some things that came up as I was trying to write a couple of examples: 1. The order in which variables are introduced is not clear---presumably it is some sort of left to write ordering based on the type signature. For example: f1 :: (a,b) -> a -- first type param is `a`? f2 :: Ord b => a -> b -> a -- first type param is `b`? type T a b = (b,a) f3 :: T a b -> a -- first type param is? This approach seems quite fragile. 2. The proposal says that a problem with the `forall` in ScopedTypeVariables is that the signature can be arbitrarily far away from the implementation. I agree that this is a problem, but it seems to remain a problem with this proposal, as you have to look at the signature to see in what order you should write the parameters. 3. There are some things that you can write with the `forall` notation, that you cannot write using this notation. For example: f3 :: forall a. Bool f3 = null ([] :: [a]) Clearly this example is a bit contrived, but still it illustrates a problem. As is, I am not sure what we are getting over ScopedTypeVariables. Am I missing something here? -Iavor On Tue, Feb 19, 2019 at 10:28 AM Iavor Diatchki wrote: > Hello, > > let's get the discussion going about proposal #155 ( > https://github.com/goldfirere/ghc-proposals/blob/type-lambda/proposals/0000-type-lambda.rst > ). > > Summary: > the idea is pretty simple: allow functions to name their type arguments > explicitly, so that they can be used in type signatures within the > function's definition. The notation for a type argument is `@a`, and such > type arguments can be used only when functions have an explicit type > signature (technically, when GHC is doing "checking" rather then > "inference"). > > This proposal provides an alternative to "ScopedTypeVariables" to refer to > type parameters, which I think is a step in the right direction, as using > the `forall` to introduce type variables always felt a bit hacky to me > (now, there's a technical argument :) > > I am a bit concerned with the notation though: in other places where we > use `@a`, (e.g., #126 type application in patterns, and TypeApplications) > the `a` is a type, while in this use it must be a variable. I wonder if > this punning might be confusing. I don't really have an alternative > suggestion though. > > What does everyone else thing? > > -Iavor > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Thu Feb 21 18:55:05 2019 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Thu, 21 Feb 2019 13:55:05 -0500 Subject: [ghc-steering-committee] Discussion on #155 Type Variable in Labmdas In-Reply-To: References: Message-ID: <62AC6480-BA69-429F-BF02-CF69CAF90417@cs.brynmawr.edu> > On Feb 19, 2019, at 2:01 PM, Iavor Diatchki wrote: > > After a bit more thought, I am not sure what do we get with this notation over ScopedTypeVariables. In particular, here are some things that came up as I was trying to write a couple of examples: > > 1. The order in which variables are introduced is not clear---presumably it is some sort of left to write ordering based on the type signature. For example: > > f1 :: (a,b) -> a -- first type param is `a`? > f2 :: Ord b => a -> b -> a -- first type param is `b`? > type T a b = (b,a) > f3 :: T a b -> a -- first type param is? > > This approach seems quite fragile. This problem first came up (in earnest) in the context of type applications. We now specify the answer in the manual; see the first two bullet-points here: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#visible-type-application These points have actually been refined in HEAD. You can view the documentation source here: https://github.com/ghc/ghc/blob/master/docs/users_guide/glasgow_exts.rst#L10800 In answer to your examples: f1: a, b f2: b, a f3: a, b > > 2. The proposal says that a problem with the `forall` in ScopedTypeVariables is that the signature can be arbitrarily far away from the implementation. I agree that this is a problem, but it seems to remain a problem with this proposal, as you have to look at the signature to see in what order you should write the parameters. Good point. > > 3. There are some things that you can write with the `forall` notation, that you cannot write using this notation. For example: > > f3 :: forall a. Bool > f3 = null ([] :: [a]) > > Clearly this example is a bit contrived, but still it illustrates a problem. You can still write `f3 @a = null ([] :: [a])`. > > As is, I am not sure what we are getting over ScopedTypeVariables. Am I missing something here? While not highlighted in the proposal, the example named `ex` binds a type variable using the new notation that would be very awkward indeed without this extension. Here is the example: higherRank :: (forall a. a -> a -> a) -> ... higherRank = ... ex = higherRank (\ @a x _y -> (x :: a)) The alternative would be to write ex = higherRank ((\ x _y -> (x :: a)) :: forall a. a -> a -> a) just to bring the `a` into scope. In the end, this proposal does not bring in much over ScopedTypeVariables -- it just makes the type-variable scoping mechanism more in line with the term-variable scoping mechanism. There's nothing fundamentally new here: just convenience. You may also want to see https://github.com/ghc-proposals/ghc-proposals/pull/155#issuecomment-459430140 and https://github.com/ghc-proposals/ghc-proposals/pull/155#issuecomment-460333687 which outline use-cases that would benefit from this new treatment. Thanks, Richard > > -Iavor > > > > > > > > > > > > > On Tue, Feb 19, 2019 at 10:28 AM Iavor Diatchki > wrote: > Hello, > > let's get the discussion going about proposal #155 (https://github.com/goldfirere/ghc-proposals/blob/type-lambda/proposals/0000-type-lambda.rst ). > > Summary: > the idea is pretty simple: allow functions to name their type arguments explicitly, so that they can be used in type signatures within the function's definition. The notation for a type argument is `@a`, and such type arguments can be used only when functions have an explicit type signature (technically, when GHC is doing "checking" rather then "inference"). > > This proposal provides an alternative to "ScopedTypeVariables" to refer to type parameters, which I think is a step in the right direction, as using the `forall` to introduce type variables always felt a bit hacky to me (now, there's a technical argument :) > > I am a bit concerned with the notation though: in other places where we use `@a`, (e.g., #126 type application in patterns, and TypeApplications) the `a` is a type, while in this use it must be a variable. I wonder if this punning might be confusing. I don't really have an alternative suggestion though. > > What does everyone else thing? > > -Iavor > _______________________________________________ > 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 Feb 22 08:05:53 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 22 Feb 2019 08:05:53 +0000 Subject: [ghc-steering-committee] Discussion on #155 Type Variable in Labmdas In-Reply-To: <62AC6480-BA69-429F-BF02-CF69CAF90417@cs.brynmawr.edu> References: <62AC6480-BA69-429F-BF02-CF69CAF90417@cs.brynmawr.edu> Message-ID: In the end, this proposal does not bring in much over ScopedTypeVariables So the gain is relatively small. But the pain is real: more complexity, and that's a long-term cost. Actually the biggest reason I like this proposal is because it takes another step in the direction of directly expressing System F in Haskell. Not so much because I expect to use it a lot but because it gives a vocabulary in which to express what a lot of the implicit elaboration in GHC is doing. I use VTA in this way already. But I'm a bit on the fence overall. With finite effort cycles, we may have more important fish to fry. Simon From: ghc-steering-committee On Behalf Of Richard Eisenberg Sent: 21 February 2019 18:55 To: Iavor Diatchki Cc: ghc-steering-committee Subject: Re: [ghc-steering-committee] Discussion on #155 Type Variable in Labmdas On Feb 19, 2019, at 2:01 PM, Iavor Diatchki > wrote: After a bit more thought, I am not sure what do we get with this notation over ScopedTypeVariables. In particular, here are some things that came up as I was trying to write a couple of examples: 1. The order in which variables are introduced is not clear---presumably it is some sort of left to write ordering based on the type signature. For example: f1 :: (a,b) -> a -- first type param is `a`? f2 :: Ord b => a -> b -> a -- first type param is `b`? type T a b = (b,a) f3 :: T a b -> a -- first type param is? This approach seems quite fragile. This problem first came up (in earnest) in the context of type applications. We now specify the answer in the manual; see the first two bullet-points here: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#visible-type-application These points have actually been refined in HEAD. You can view the documentation source here: https://github.com/ghc/ghc/blob/master/docs/users_guide/glasgow_exts.rst#L10800 In answer to your examples: f1: a, b f2: b, a f3: a, b 2. The proposal says that a problem with the `forall` in ScopedTypeVariables is that the signature can be arbitrarily far away from the implementation. I agree that this is a problem, but it seems to remain a problem with this proposal, as you have to look at the signature to see in what order you should write the parameters. Good point. 3. There are some things that you can write with the `forall` notation, that you cannot write using this notation. For example: f3 :: forall a. Bool f3 = null ([] :: [a]) Clearly this example is a bit contrived, but still it illustrates a problem. You can still write `f3 @a = null ([] :: [a])`. As is, I am not sure what we are getting over ScopedTypeVariables. Am I missing something here? While not highlighted in the proposal, the example named `ex` binds a type variable using the new notation that would be very awkward indeed without this extension. Here is the example: higherRank :: (forall a. a -> a -> a) -> ... higherRank = ... ex = higherRank (\ @a x _y -> (x :: a)) The alternative would be to write ex = higherRank ((\ x _y -> (x :: a)) :: forall a. a -> a -> a) just to bring the `a` into scope. In the end, this proposal does not bring in much over ScopedTypeVariables -- it just makes the type-variable scoping mechanism more in line with the term-variable scoping mechanism. There's nothing fundamentally new here: just convenience. You may also want to see https://github.com/ghc-proposals/ghc-proposals/pull/155#issuecomment-459430140 and https://github.com/ghc-proposals/ghc-proposals/pull/155#issuecomment-460333687 which outline use-cases that would benefit from this new treatment. Thanks, Richard -Iavor On Tue, Feb 19, 2019 at 10:28 AM Iavor Diatchki > wrote: Hello, let's get the discussion going about proposal #155 (https://github.com/goldfirere/ghc-proposals/blob/type-lambda/proposals/0000-type-lambda.rst). Summary: the idea is pretty simple: allow functions to name their type arguments explicitly, so that they can be used in type signatures within the function's definition. The notation for a type argument is `@a`, and such type arguments can be used only when functions have an explicit type signature (technically, when GHC is doing "checking" rather then "inference"). This proposal provides an alternative to "ScopedTypeVariables" to refer to type parameters, which I think is a step in the right direction, as using the `forall` to introduce type variables always felt a bit hacky to me (now, there's a technical argument :) I am a bit concerned with the notation though: in other places where we use `@a`, (e.g., #126 type application in patterns, and TypeApplications) the `a` is a type, while in this use it must be a variable. I wonder if this punning might be confusing. I don't really have an alternative suggestion though. What does everyone else thing? -Iavor _______________________________________________ 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 vlad.z.4096 at gmail.com Fri Feb 22 10:48:34 2019 From: vlad.z.4096 at gmail.com (Vladislav Zavialov) Date: Fri, 22 Feb 2019 13:48:34 +0300 Subject: [ghc-steering-committee] Discussion on #155 Type Variable in Labmdas In-Reply-To: References: <62AC6480-BA69-429F-BF02-CF69CAF90417@cs.brynmawr.edu> Message-ID: Dear GHC steering committee, > In the end, this proposal does not bring in much over ScopedTypeVariables Please note that comparing this feature to ScopedTypeVariables does not capture the full picture. There are two examples of code in the proposal, which I provided, that cannot be expressed using ScopedTypeVariables without a dummy Proxy argument. > With finite effort cycles, we may have more important fish to fry. I was planning to implement this proposal if it would be accepted. All the best, - Vladislav From iavor.diatchki at gmail.com Fri Feb 22 17:22:31 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 22 Feb 2019 09:22:31 -0800 Subject: [ghc-steering-committee] Discussion on #155 Type Variable in Labmdas In-Reply-To: References: <62AC6480-BA69-429F-BF02-CF69CAF90417@cs.brynmawr.edu> Message-ID: Hello, my concern is mainly with introducing multiple language constructs that do almost the same thing and neither is better than the other as I think this complicates the language unnecessarily. Vladislav, I am not sure of the details of your example, but isn't it the case that you could write it with scoped type variables if you wrote the type down? I agree that this can be a pain, and as far as I see, this is the main use case for this feature---it provides an easier way to call higher-rank functions, when you need to refer to the type parameter in the polymorphic argument. -Iavor On Fri, Feb 22, 2019 at 2:48 AM Vladislav Zavialov wrote: > Dear GHC steering committee, > > > In the end, this proposal does not bring in much over ScopedTypeVariables > > Please note that comparing this feature to ScopedTypeVariables does > not capture the full picture. There are two examples of code in the > proposal, which I provided, that cannot be expressed using > ScopedTypeVariables without a dummy Proxy argument. > > > With finite effort cycles, we may have more important fish to fry. > > I was planning to implement this proposal if it would be accepted. > > All the best, > - Vladislav > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vlad.z.4096 at gmail.com Fri Feb 22 17:55:06 2019 From: vlad.z.4096 at gmail.com (Vladislav Zavialov) Date: Fri, 22 Feb 2019 20:55:06 +0300 Subject: [ghc-steering-committee] Discussion on #155 Type Variable in Labmdas In-Reply-To: References: <62AC6480-BA69-429F-BF02-CF69CAF90417@cs.brynmawr.edu> Message-ID: > isn't it the case that you could write it with scoped type variables if you wrote the type down? I don't think so, the type does not necessarily mention the type variables. For example, imagine we removed Proxy from reflection: reify :: forall a r. a -> (forall s. Reifies s a => r) -> r reflect :: forall s a. Reifies s a => a Under this proposal, I would be able to write x = reify (\ @s -> reflect @s + reflect @s) (5 :: Integer) Here, x = 10 :: Integer. ScopedTypeVariables require extra Proxy arguments to express this, which are not only an inconvenience, but also extra data passed at runtime. Same reasoning applies to other higher-rank situations, including my other example with CPS-d proofs. All the best, - Vladislav From iavor.diatchki at gmail.com Fri Feb 22 18:59:00 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 22 Feb 2019 10:59:00 -0800 Subject: [ghc-steering-committee] Discussion on #155 Type Variable in Labmdas In-Reply-To: References: <62AC6480-BA69-429F-BF02-CF69CAF90417@cs.brynmawr.edu> Message-ID: Hello, I assume the arguments to `reify` are meant to be the other way around? Here is the ScopedTypeVariables version I thought should work but indeed it doesn't, although I don't fully understand why. Is it because GHC instantiates `val` and then tries to generalize again, but fails since the polymorphic argument to `reify` is very ambiguous? And is this the intended behavior? {-# Language ScopedTypeVariables #-} {-# Language RankNTypes #-} {-# Language TypeApplications #-} {-# Language MultiParamTypeClasses #-} {-# Language FlexibleContexts #-} {-# Language AllowAmbiguousTypes #-} class Reifies s a reify :: forall a r. a -> (forall s. Reifies s a => r) -> r reify _ _ = undefined reflect :: forall s a. Reifies s a => a reflect = undefined example = reify 5 val where val :: forall s. Reifies s Integer => Integer val = reflect @s + reflect @s On Fri, Feb 22, 2019 at 9:55 AM Vladislav Zavialov wrote: > > isn't it the case that you could write it with scoped type variables if > you wrote the type down? > > I don't think so, the type does not necessarily mention the type > variables. For example, imagine we removed Proxy from reflection: > > reify :: forall a r. a -> (forall s. Reifies s a => r) -> r > reflect :: forall s a. Reifies s a => a > > Under this proposal, I would be able to write > > x = reify (\ @s -> reflect @s + reflect @s) (5 :: Integer) > > Here, x = 10 :: Integer. > > ScopedTypeVariables require extra Proxy arguments to express this, > which are not only an inconvenience, but also extra data passed at > runtime. Same reasoning applies to other higher-rank situations, > including my other example with CPS-d proofs. > > All the best, > - Vladislav > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Feb 27 10:25:14 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 27 Feb 2019 11:25:14 +0100 Subject: [ghc-steering-committee] Please review #209: Levity Polymorphic Lift, Shepherd: Eric Seidel Message-ID: Dear Committee, this is your secretary speaking: Levity polymorphic lift has been proposed by Alec Theiault https://github.com/ghc-proposals/ghc-proposals/pull/209 https://github.com/harpocrates/ghc-proposals/blob/levity-polymorphic-lift/proposals/0000-levity-polymorphic-lift.rst I propose Erid Seidel as the shepherd. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, 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: