Please review #176: SCC Parsing, Shepherd: Simon M

older
Proposal #209: Levity polymorphic...

Joachim Breitner

3 Feb 2019 3 Feb '19

5:48 p.m.

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-s... 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@joachim-breitner.de http://www.joachim-breitner.de/

Attachments:

signature.asc (application/pgp-signature — 833 bytes)

Show replies by date

Simon Marlow

6 Feb 6 Feb

3:35 a.m.

New subject: #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-s...) 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-s...

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@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Simon Peyton Jones

10:47 a.m.

New subject: #176: SCC Parsing, recommendation: accept

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@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-s...https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fint-index%2Fghc-proposals%2Fblob%2Fscc-parsing%2Fproposals%2F0000-scc-parsing.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C789be33375494f9342ae08d68c0e227b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636850389679271674&sdata=TJveWEMTpahWPnxeQ4m%2FMLn%2FG3jLvlEXtyDFBQAKCUA%3D&reserved=0) 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 mailto:mail@joachim-breitner.de> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F176&data=02%7C01%7Csimonpj%40microsoft.com%7C789be33375494f9342ae08d68c0e227b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636850389679271674&sdata=SfuBj889NVTj4zh%2FNXU4NMErRH4vihXEgwcc95IkNPE%3D&reserved=0 https://github.com/int-index/ghc-proposals/blob/scc-parsing/proposals/0000-s...https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fint-index%2Fghc-proposals%2Fblob%2Fscc-parsing%2Fproposals%2F0000-scc-parsing.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C789be33375494f9342ae08d68c0e227b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636850389679281668&sdata=Pk3OCZvv4L%2BN57sFRF%2BZ%2BqoBReZ3QoR1O%2F2xi7abY8g%3D&reserved=0 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 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=02%7C01%7Csimonpj%40microsoft.com%7C789be33375494f9342ae08d68c0e227b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636850389679281668&sdata=bI75BzUzn%2BCiPb183kIOdZ3%2BX1PNWxItiXuNOONswSc%3D&reserved=0 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@joachim-breitner.demailto:mail@joachim-breitner.de http://www.joachim-breitner.de/https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C789be33375494f9342ae08d68c0e227b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636850389679291663&sdata=ST5c032JWNAMCoWhMVUryca02Mmg8Bnfd%2FgmXMCRoA0%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C789be33375494f9342ae08d68c0e227b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636850389679291663&sdata=KZQCrGQeoWjKk6sV20IGWVPk%2BHzzEsruSJLdGasKtUo%3D&reserved=0

Richard Eisenberg

11:17 a.m.

New subject: #176: SCC Parsing, recommendation: accept

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@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-s... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fint-index%2Fghc-proposals%2Fblob%2Fscc-parsing%2Fproposals%2F0000-scc-parsing.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C789be33375494f9342ae08d68c0e227b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636850389679271674&sdata=TJveWEMTpahWPnxeQ4m%2FMLn%2FG3jLvlEXtyDFBQAKCUA%3D&reserved=0) 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 mailto:mail@joachim-breitner.de> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F176&data=02%7C01%7Csimonpj%40microsoft.com%7C789be33375494f9342ae08d68c0e227b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636850389679271674&sdata=SfuBj889NVTj4zh%2FNXU4NMErRH4vihXEgwcc95IkNPE%3D&reserved=0 https://github.com/int-index/ghc-proposals/blob/scc-parsing/proposals/0000-s... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fint-index%2Fghc-proposals%2Fblob%2Fscc-parsing%2Fproposals%2F0000-scc-parsing.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C789be33375494f9342ae08d68c0e227b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636850389679281668&sdata=Pk3OCZvv4L%2BN57sFRF%2BZ%2BqoBReZ3QoR1O%2F2xi7abY8g%3D&reserved=0

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 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=02%7C01%7Csimonpj%40microsoft.com%7C789be33375494f9342ae08d68c0e227b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636850389679281668&sdata=bI75BzUzn%2BCiPb183kIOdZ3%2BX1PNWxItiXuNOONswSc%3D&reserved=0 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@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C789be33375494f9342ae08d68c0e227b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636850389679291663&sdata=ST5c032JWNAMCoWhMVUryca02Mmg8Bnfd%2FgmXMCRoA0%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C789be33375494f9342ae08d68c0e227b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636850389679291663&sdata=KZQCrGQeoWjKk6sV20IGWVPk%2BHzzEsruSJLdGasKtUo%3D&reserved=0_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Manuel M T Chakravarty

11:40 a.m.

New subject: #176: SCC Parsing, recommendation: accept

...

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-s... https://github.com/int-index/ghc-proposals/blob/scc-parsing/proposals/0000-s...) 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 mailto:mail@joachim-breitner.de> 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/ghc-proposals/ghc-proposals/pull/176 https://github.com/int-index/ghc-proposals/blob/scc-parsing/proposals/0000-s... https://github.com/int-index/ghc-proposals/blob/scc-parsing/proposals/0000-s...

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 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@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Joachim Breitner

17 Apr 17 Apr

3:05 a.m.

New subject: #176: SCC Parsing, recommendation: accept

Hi, Am Mittwoch, den 06.02.2019, 08:35 +0000 schrieb marlowsd at gmail.com:

...

So, I propose we accept this.

accepted. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Joachim Breitner

2 Mar 2 Mar

11:16 a.m.

New subject: #210: -Wredundant-minimal-methods, recommendation: accept

Dear Committee, Levent Erkök has proposed to introduce a warning when a type class specifies a methods as definitely requires (via a MINIMAL pragma), but still gives a default implementation: https://github.com/LeventErkok/ghc-proposals/blob/master/proposals/0000-mini... This seems both useful and and harmless to me, so I propose we accept the proposal. If we want to do some bike shedding: I think -Wredundant-minimal-methods has a better flow than the proposed -Wminimal-redundant-methods After all, we want to be warned about redundancy of minimal methods, not minimality of redundant methods. Cheers, Simon

Iavor Diatchki

7:27 p.m.

New subject: #210: -Wredundant-minimal-methods, recommendation: accept

I am on board. And I like "redundant minimal" better On Sat, Mar 2, 2019, 08:16 Joachim Breitner wrote:

...

Dear Committee,

Levent Erkök has proposed to introduce a warning when a type class specifies a methods as definitely requires (via a MINIMAL pragma), but still gives a default implementation:

https://github.com/LeventErkok/ghc-proposals/blob/master/proposals/0000-mini...

This seems both useful and and harmless to me, so I propose we accept the proposal.

If we want to do some bike shedding: I think -Wredundant-minimal-methods has a better flow than the proposed -Wminimal-redundant-methods After all, we want to be warned about redundancy of minimal methods, not minimality of redundant methods.

Cheers, Simon

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Simon Peyton Jones

4 Mar 4 Mar

6:41 a.m.

New subject: #210: -Wredundant-minimal-methods, recommendation: accept

I'm happy to support this. And yes "-Wredundant-minimal-methods" Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Joachim Breitner | Sent: 02 March 2019 16:17 | To: ghc-steering-committee@haskell.org | Subject: [ghc-steering-committee] #210: -Wredundant-minimal-methods, | recommendation: accept | | Dear Committee, | | Levent Erkök has proposed to introduce a warning when a type class | specifies a methods as definitely requires (via a MINIMAL pragma), but | still gives a default implementation: | https://github.com/LeventErkok/ghc-proposals/blob/master/proposals/0000- | minimal-should-warn-extras.rst | | This seems both useful and and harmless to me, so I propose we accept | the proposal. | | If we want to do some bike shedding: I think | -Wredundant-minimal-methods | has a better flow than the proposed | -Wminimal-redundant-methods | After all, we want to be warned about redundancy of minimal methods, | not minimality of redundant methods. | | Cheers, | Simon | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Joachim Breitner

14 Mar 14 Mar

10:48 a.m.

New subject: #210: -Wredundant-minimal-methods, recommendation: accept

Hi, great, I’ll marks this as accepted, with "-Wredundant-minimal-methods". Cheers, Joachim Am Montag, den 04.03.2019, 11:41 +0000 schrieb Simon Peyton Jones via ghc-steering-committee:

...

I'm happy to support this. And yes

Simon

...
-----Original Message----- From: ghc-steering-committee On Behalf Of Joachim Breitner Sent: 02 March 2019 16:17 To: ghc-steering-committee@haskell.org Subject: [ghc-steering-committee] #210: -Wredundant-minimal-methods, recommendation: accept

Dear Committee,

Levent Erkök has proposed to introduce a warning when a type class specifies a methods as definitely requires (via a MINIMAL pragma), but still gives a default implementation: https://github.com/LeventErkok/ghc-proposals/blob/master/proposals/0000- minimal-should-warn-extras.rst

This seems both useful and and harmless to me, so I propose we accept the proposal.

If we want to do some bike shedding: I think -Wredundant-minimal-methods has a better flow than the proposed -Wminimal-redundant-methods After all, we want to be warned about redundancy of minimal methods, not minimality of redundant methods.

Cheers, Simon

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Joachim Breitner

10:47 a.m.

New subject: #179: Tweak the printing of foralls, recommendation: accept

Dear Committee, Richard, in collarboration with Simon PJ, proposes some tweaks to how foralls are printed by GHC. In particular, whenever a type variable is printed with an forall, it is printed with {a} unless it is a specified variable. And there are tweaks to what :type does with its argument that makes it more useful, and obviates the need for a separate :type +v. https://github.com/goldfirere/ghc-proposals/blob/printing-foralls/proposals/... I like that it actually simplifies the UI (by removing :type +v), so I recommend acceptance. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Iavor Diatchki

6:18 p.m.

New subject: #179: Tweak the printing of foralls, recommendation: accept

Overall I am all for simplifying this stuff, but the bit where constraints with no variables are not simplified seems quite confusing. More concretely, using the example from the proposal: bar :: forall a b. (a ~ Int) => a -> b -> a Is it the case that `:t bar @Bool` will print bar :: (Bool ~ Int) => Bool -> b -> Bool This looks particularly confusing without the explicit `forall`, although it seems questionable either way. -Iavor On Thu, Mar 14, 2019 at 7:47 AM Joachim Breitner wrote:

...

Dear Committee,

Richard, in collarboration with Simon PJ, proposes some tweaks to how foralls are printed by GHC.

In particular, whenever a type variable is printed with an forall, it is printed with {a} unless it is a specified variable. And there are tweaks to what :type does with its argument that makes it more useful, and obviates the need for a separate :type +v.

https://github.com/goldfirere/ghc-proposals/blob/printing-foralls/proposals/...

I like that it actually simplifies the UI (by removing :type +v), so I recommend acceptance.

Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEGkYIf5Vdk8V8YFcbPZCKs/D79R8FAlyKaX8ACgkQPZCKs/D7 9R/7oxAAgU213SuV+1lr/JExnMSPNWD6s7CPTWdauLK+tHYUv1MD3HeZlBZb2pvN R/swC6jdm95vKXWeMVhfYGFGepOdMEKzqBWLDf3fCO29MlHlb4barwtEZOZ9AbaM DSyE+RjVQ35ATZPvfFTYdBacBrvCivoRWcUdi10ps6rizI86gKeCiG1PN5nVMNV+ cpvTpFWRm/xmbtU4xFWuZ9FjL0bfO6yJCueX07gTkdZYW4vnvWSdis6CInkQZ7SA hXbTEYNT9zMCGvJMG+NQN+5c0h3GJlUoTsNGd0PsQnkvoYiLjM52eM5hzkz5zFRr mMYT381T1nnIl505IFGuT/je5KAn7wTImIXvvclwDxfjCBn3J1IRVAbikgwlTU4M 9L+tlQiTKI8OZpbgpPjjRj4hWrnX1gzWiIGwtPYtQuPhkDhEvq0xex8qEKpd7waE r5klTYyZrC0LGaHyX5G5yunGLWqnlLKOHAPI20Z1bxVPtDJZ/4g6AoCYSNqBLsHt fMTFflHdKTlsCOETPGhaxgf6PP0WvZtNdgTrB2rL5jzKJSOKc1rVRFAdYIr5PP3H c4aZGce/ChyFazHeF7hH5UZ7yyB0gMc3T+do6I8vySp0YGeRweb36FU13CduMS05 rvzb6GIkNFz/Fx2MascE9kZtGvDT9BlxGXqJ9rL/huXquIwN6Gg= =1qbg -----END PGP SIGNATURE----- _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Richard Eisenberg

7:45 p.m.

New subject: #179: Tweak the printing of foralls, recommendation: accept

...

On Mar 14, 2019, at 6:18 PM, Iavor Diatchki wrote:

bar :: forall a b. (a ~ Int) => a -> b -> a

Is it the case that `:t bar @Bool` will print

bar :: (Bool ~ Int) => Bool -> b -> Bool

This looks particularly confusing without the explicit `forall`, although it seems questionable either way.

Yes, you understand correctly. `:t bar @Bool` will print that unfortunate type. I agree this is questionable. But I don't know how to do better. The current state of affairs is awkward in a different way, in that `:t bar @Bool` errors (that's OK) and `:t bar @Int` prints `forall {b}. Int -> b -> Int`, even though a further visible type application is possible. Perhaps worse, `:t bar` today prints `forall {b}. Int -> b -> Int` even though the next variable to be instantiated is `a`. This is why we have `:type +v`. The direction in the proposal came about in wondering if it's possible to improve the mechanics of `:t` (without the `+v`). After we thought of doing maximal instantiation of inferred arguments (but no generalization), then we realized we could drop `:type +v` as redundant. I agree it's something of an uneasy compromise here, but I think any choice is going to have unfortunate behavior in some scenarios. Richard

...

-Iavor

On Thu, Mar 14, 2019 at 7:47 AM Joachim Breitner mailto:mail@joachim-breitner.de> wrote: Dear Committee,

Richard, in collarboration with Simon PJ, proposes some tweaks to how foralls are printed by GHC.

In particular, whenever a type variable is printed with an forall, it is printed with {a} unless it is a specified variable. And there are tweaks to what :type does with its argument that makes it more useful, and obviates the need for a separate :type +v. https://github.com/goldfirere/ghc-proposals/blob/printing-foralls/proposals/... https://github.com/goldfirere/ghc-proposals/blob/printing-foralls/proposals/...

I like that it actually simplifies the UI (by removing :type +v), so I recommend acceptance.

Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ http://www.joachim-breitner.de/

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEGkYIf5Vdk8V8YFcbPZCKs/D79R8FAlyKaX8ACgkQPZCKs/D7 9R/7oxAAgU213SuV+1lr/JExnMSPNWD6s7CPTWdauLK+tHYUv1MD3HeZlBZb2pvN R/swC6jdm95vKXWeMVhfYGFGepOdMEKzqBWLDf3fCO29MlHlb4barwtEZOZ9AbaM DSyE+RjVQ35ATZPvfFTYdBacBrvCivoRWcUdi10ps6rizI86gKeCiG1PN5nVMNV+ cpvTpFWRm/xmbtU4xFWuZ9FjL0bfO6yJCueX07gTkdZYW4vnvWSdis6CInkQZ7SA hXbTEYNT9zMCGvJMG+NQN+5c0h3GJlUoTsNGd0PsQnkvoYiLjM52eM5hzkz5zFRr mMYT381T1nnIl505IFGuT/je5KAn7wTImIXvvclwDxfjCBn3J1IRVAbikgwlTU4M 9L+tlQiTKI8OZpbgpPjjRj4hWrnX1gzWiIGwtPYtQuPhkDhEvq0xex8qEKpd7waE r5klTYyZrC0LGaHyX5G5yunGLWqnlLKOHAPI20Z1bxVPtDJZ/4g6AoCYSNqBLsHt fMTFflHdKTlsCOETPGhaxgf6PP0WvZtNdgTrB2rL5jzKJSOKc1rVRFAdYIr5PP3H c4aZGce/ChyFazHeF7hH5UZ7yyB0gMc3T+do6I8vySp0YGeRweb36FU13CduMS05 rvzb6GIkNFz/Fx2MascE9kZtGvDT9BlxGXqJ9rL/huXquIwN6Gg= =1qbg -----END PGP SIGNATURE----- _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Simon Peyton Jones

15 Mar 15 Mar

4:26 a.m.

New subject: #179: Tweak the printing of foralls, recommendation: accept

This looks particularly confusing without the explicit `forall`, although it seems questionable either way. Why? GHC often suppresses foralls when printing types; and had -fprint-explicit-foralls to stop doing that. Simon From: ghc-steering-committee On Behalf Of Richard Eisenberg Sent: 14 March 2019 23:46 To: Iavor Diatchki Cc: ghc-steering-committee@haskell.org; Joachim Breitner Subject: Re: [ghc-steering-committee] #179: Tweak the printing of foralls, recommendation: accept On Mar 14, 2019, at 6:18 PM, Iavor Diatchki mailto:iavor.diatchki@gmail.com> wrote: bar :: forall a b. (a ~ Int) => a -> b -> a Is it the case that `:t bar @Bool` will print bar :: (Bool ~ Int) => Bool -> b -> Bool This looks particularly confusing without the explicit `forall`, although it seems questionable either way. Yes, you understand correctly. `:t bar @Bool` will print that unfortunate type. I agree this is questionable. But I don't know how to do better. The current state of affairs is awkward in a different way, in that `:t bar @Bool` errors (that's OK) and `:t bar @Int` prints `forall {b}. Int -> b -> Int`, even though a further visible type application is possible. Perhaps worse, `:t bar` today prints `forall {b}. Int -> b -> Int` even though the next variable to be instantiated is `a`. This is why we have `:type +v`. The direction in the proposal came about in wondering if it's possible to improve the mechanics of `:t` (without the `+v`). After we thought of doing maximal instantiation of inferred arguments (but no generalization), then we realized we could drop `:type +v` as redundant. I agree it's something of an uneasy compromise here, but I think any choice is going to have unfortunate behavior in some scenarios. Richard -Iavor On Thu, Mar 14, 2019 at 7:47 AM Joachim Breitner mailto:mail@joachim-breitner.de> wrote: Dear Committee, Richard, in collarboration with Simon PJ, proposes some tweaks to how foralls are printed by GHC. In particular, whenever a type variable is printed with an forall, it is printed with {a} unless it is a specified variable. And there are tweaks to what :type does with its argument that makes it more useful, and obviates the need for a separate :type +v. https://github.com/goldfirere/ghc-proposals/blob/printing-foralls/proposals/... I like that it actually simplifies the UI (by removing :type +v), so I recommend acceptance. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.demailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEGkYIf5Vdk8V8YFcbPZCKs/D79R8FAlyKaX8ACgkQPZCKs/D7 9R/7oxAAgU213SuV+1lr/JExnMSPNWD6s7CPTWdauLK+tHYUv1MD3HeZlBZb2pvN R/swC6jdm95vKXWeMVhfYGFGepOdMEKzqBWLDf3fCO29MlHlb4barwtEZOZ9AbaM DSyE+RjVQ35ATZPvfFTYdBacBrvCivoRWcUdi10ps6rizI86gKeCiG1PN5nVMNV+ cpvTpFWRm/xmbtU4xFWuZ9FjL0bfO6yJCueX07gTkdZYW4vnvWSdis6CInkQZ7SA hXbTEYNT9zMCGvJMG+NQN+5c0h3GJlUoTsNGd0PsQnkvoYiLjM52eM5hzkz5zFRr mMYT381T1nnIl505IFGuT/je5KAn7wTImIXvvclwDxfjCBn3J1IRVAbikgwlTU4M 9L+tlQiTKI8OZpbgpPjjRj4hWrnX1gzWiIGwtPYtQuPhkDhEvq0xex8qEKpd7waE r5klTYyZrC0LGaHyX5G5yunGLWqnlLKOHAPI20Z1bxVPtDJZ/4g6AoCYSNqBLsHt fMTFflHdKTlsCOETPGhaxgf6PP0WvZtNdgTrB2rL5jzKJSOKc1rVRFAdYIr5PP3H c4aZGce/ChyFazHeF7hH5UZ7yyB0gMc3T+do6I8vySp0YGeRweb36FU13CduMS05 rvzb6GIkNFz/Fx2MascE9kZtGvDT9BlxGXqJ9rL/huXquIwN6Gg= =1qbg -----END PGP SIGNATURE----- _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Iavor Diatchki

1:04 p.m.

New subject: #179: Tweak the printing of foralls, recommendation: accept

I just mean that without explicit foralls the fact that there is another quantified variable is not quite obvious, and so to me it looks quite surprising that the context didn't get simplified. This is a bit orthogonal, but what would you expect to see in this case: type T b = Bool bar :: (a ~ Int) => a -> T b -> a :t bar :t bar @Bool I guess the answer to these depends on if `b` is quantified or not. On Fri, Mar 15, 2019 at 1:26 AM Simon Peyton Jones wrote:

...

This looks particularly confusing without the explicit `forall`, although it seems questionable either way.

Why? GHC often suppresses foralls when printing types; and had -fprint-explicit-foralls to stop doing that.

Simon

*From:* ghc-steering-committee *On Behalf Of *Richard Eisenberg *Sent:* 14 March 2019 23:46 *To:* Iavor Diatchki *Cc:* ghc-steering-committee@haskell.org; Joachim Breitner < mail@joachim-breitner.de> *Subject:* Re: [ghc-steering-committee] #179: Tweak the printing of foralls, recommendation: accept

On Mar 14, 2019, at 6:18 PM, Iavor Diatchki wrote:

bar :: forall a b. (a ~ Int) => a -> b -> a

Is it the case that `:t bar @Bool` will print

bar :: (Bool ~ Int) => Bool -> b -> Bool

This looks particularly confusing without the explicit `forall`, although it seems questionable either way.

Yes, you understand correctly. `:t bar @Bool` will print that unfortunate type. I agree this is questionable. But I don't know how to do better. The current state of affairs is awkward in a different way, in that `:t bar @Bool` errors (that's OK) and `:t bar @Int` prints `forall {b}. Int -> b -> Int`, even though a further visible type application is possible. Perhaps worse, `:t bar` today prints `forall {b}. Int -> b -> Int` even though the next variable to be instantiated is `a`. This is why we have `:type +v`.

The direction in the proposal came about in wondering if it's possible to improve the mechanics of `:t` (without the `+v`). After we thought of doing maximal instantiation of inferred arguments (but no generalization), then we realized we could drop `:type +v` as redundant. I agree it's something of an uneasy compromise here, but I think any choice is going to have unfortunate behavior in some scenarios.

Richard

-Iavor

On Thu, Mar 14, 2019 at 7:47 AM Joachim Breitner wrote:

Dear Committee,

Richard, in collarboration with Simon PJ, proposes some tweaks to how foralls are printed by GHC.

In particular, whenever a type variable is printed with an forall, it is printed with {a} unless it is a specified variable. And there are tweaks to what :type does with its argument that makes it more useful, and obviates the need for a separate :type +v.

https://github.com/goldfirere/ghc-proposals/blob/printing-foralls/proposals/...

I like that it actually simplifies the UI (by removing :type +v), so I recommend acceptance.

Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEGkYIf5Vdk8V8YFcbPZCKs/D79R8FAlyKaX8ACgkQPZCKs/D7 9R/7oxAAgU213SuV+1lr/JExnMSPNWD6s7CPTWdauLK+tHYUv1MD3HeZlBZb2pvN R/swC6jdm95vKXWeMVhfYGFGepOdMEKzqBWLDf3fCO29MlHlb4barwtEZOZ9AbaM DSyE+RjVQ35ATZPvfFTYdBacBrvCivoRWcUdi10ps6rizI86gKeCiG1PN5nVMNV+ cpvTpFWRm/xmbtU4xFWuZ9FjL0bfO6yJCueX07gTkdZYW4vnvWSdis6CInkQZ7SA hXbTEYNT9zMCGvJMG+NQN+5c0h3GJlUoTsNGd0PsQnkvoYiLjM52eM5hzkz5zFRr mMYT381T1nnIl505IFGuT/je5KAn7wTImIXvvclwDxfjCBn3J1IRVAbikgwlTU4M 9L+tlQiTKI8OZpbgpPjjRj4hWrnX1gzWiIGwtPYtQuPhkDhEvq0xex8qEKpd7waE r5klTYyZrC0LGaHyX5G5yunGLWqnlLKOHAPI20Z1bxVPtDJZ/4g6AoCYSNqBLsHt fMTFflHdKTlsCOETPGhaxgf6PP0WvZtNdgTrB2rL5jzKJSOKc1rVRFAdYIr5PP3H c4aZGce/ChyFazHeF7hH5UZ7yyB0gMc3T+do6I8vySp0YGeRweb36FU13CduMS05 rvzb6GIkNFz/Fx2MascE9kZtGvDT9BlxGXqJ9rL/huXquIwN6Gg= =1qbg -----END PGP SIGNATURE----- _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Richard Eisenberg

2:03 p.m.

New subject: #179: Tweak the printing of foralls, recommendation: accept

...

On Mar 15, 2019, at 1:04 PM, Iavor Diatchki wrote:

This is a bit orthogonal, but what would you expect to see in this case:

type T b = Bool bar :: (a ~ Int) => a -> T b -> a

:t bar

Without -fprint-explicit-foralls: (a ~ Int) => a -> T b -> a With -fprint-explicit-foralls: forall a b. (a ~ Int) => a -> T b -> a

...

:t bar @Bool

Without -fprint-explicit-foralls: (Bool ~ Int) => Bool -> T b -> Bool With -fprint-explicit-foralls: forall b. (Bool ~ Int) => Bool -> T b -> Bool

...

I guess the answer to these depends on if `b` is quantified or not.

b *is* quantified -- the quantification happens on the type as the user writes it. Richard

...

On Fri, Mar 15, 2019 at 1:26 AM Simon Peyton Jones mailto:simonpj@microsoft.com> wrote: This looks particularly confusing without the explicit `forall`, although it seems questionable either way.

Why? GHC often suppresses foralls when printing types; and had -fprint-explicit-foralls to stop doing that.

Simon

From: ghc-steering-committee mailto:ghc-steering-committee-bounces@haskell.org> On Behalf Of Richard Eisenberg Sent: 14 March 2019 23:46 To: Iavor Diatchki mailto:iavor.diatchki@gmail.com> Cc: ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org; Joachim Breitner mailto:mail@joachim-breitner.de> Subject: Re: [ghc-steering-committee] #179: Tweak the printing of foralls, recommendation: accept

On Mar 14, 2019, at 6:18 PM, Iavor Diatchki mailto:iavor.diatchki@gmail.com> wrote:

bar :: forall a b. (a ~ Int) => a -> b -> a

Is it the case that `:t bar @Bool` will print

bar :: (Bool ~ Int) => Bool -> b -> Bool

This looks particularly confusing without the explicit `forall`, although it seems questionable either way.

Yes, you understand correctly. `:t bar @Bool` will print that unfortunate type. I agree this is questionable. But I don't know how to do better. The current state of affairs is awkward in a different way, in that `:t bar @Bool` errors (that's OK) and `:t bar @Int` prints `forall {b}. Int -> b -> Int`, even though a further visible type application is possible. Perhaps worse, `:t bar` today prints `forall {b}. Int -> b -> Int` even though the next variable to be instantiated is `a`. This is why we have `:type +v`.

The direction in the proposal came about in wondering if it's possible to improve the mechanics of `:t` (without the `+v`). After we thought of doing maximal instantiation of inferred arguments (but no generalization), then we realized we could drop `:type +v` as redundant. I agree it's something of an uneasy compromise here, but I think any choice is going to have unfortunate behavior in some scenarios.

Richard

-Iavor

On Thu, Mar 14, 2019 at 7:47 AM Joachim Breitner mailto:mail@joachim-breitner.de> wrote:

Dear Committee,

Richard, in collarboration with Simon PJ, proposes some tweaks to how foralls are printed by GHC.

In particular, whenever a type variable is printed with an forall, it is printed with {a} unless it is a specified variable. And there are tweaks to what :type does with its argument that makes it more useful, and obviates the need for a separate :type +v. https://github.com/goldfirere/ghc-proposals/blob/printing-foralls/proposals/... https://github.com/goldfirere/ghc-proposals/blob/printing-foralls/proposals/...

I like that it actually simplifies the UI (by removing :type +v), so I recommend acceptance.

Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ http://www.joachim-breitner.de/

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEGkYIf5Vdk8V8YFcbPZCKs/D79R8FAlyKaX8ACgkQPZCKs/D7 9R/7oxAAgU213SuV+1lr/JExnMSPNWD6s7CPTWdauLK+tHYUv1MD3HeZlBZb2pvN R/swC6jdm95vKXWeMVhfYGFGepOdMEKzqBWLDf3fCO29MlHlb4barwtEZOZ9AbaM DSyE+RjVQ35ATZPvfFTYdBacBrvCivoRWcUdi10ps6rizI86gKeCiG1PN5nVMNV+ cpvTpFWRm/xmbtU4xFWuZ9FjL0bfO6yJCueX07gTkdZYW4vnvWSdis6CInkQZ7SA hXbTEYNT9zMCGvJMG+NQN+5c0h3GJlUoTsNGd0PsQnkvoYiLjM52eM5hzkz5zFRr mMYT381T1nnIl505IFGuT/je5KAn7wTImIXvvclwDxfjCBn3J1IRVAbikgwlTU4M 9L+tlQiTKI8OZpbgpPjjRj4hWrnX1gzWiIGwtPYtQuPhkDhEvq0xex8qEKpd7waE r5klTYyZrC0LGaHyX5G5yunGLWqnlLKOHAPI20Z1bxVPtDJZ/4g6AoCYSNqBLsHt fMTFflHdKTlsCOETPGhaxgf6PP0WvZtNdgTrB2rL5jzKJSOKc1rVRFAdYIr5PP3H c4aZGce/ChyFazHeF7hH5UZ7yyB0gMc3T+do6I8vySp0YGeRweb36FU13CduMS05 rvzb6GIkNFz/Fx2MascE9kZtGvDT9BlxGXqJ9rL/huXquIwN6Gg= =1qbg -----END PGP SIGNATURE----- _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Joachim Breitner

17 Apr 17 Apr

3:01 a.m.

New subject: #179: Tweak the printing of foralls, recommendation: accept

Hi Iavor, have these explanations helped your understanding here? Do they address your concerns? Cheers, Joachim Am Freitag, den 15.03.2019, 14:03 -0400 schrieb Richard Eisenberg:

...

On Mar 15, 2019, at 1:04 PM, Iavor Diatchki wrote:

...
This is a bit orthogonal, but what would you expect to see in this case:

type T b = Bool bar :: (a ~ Int) => a -> T b -> a

:t bar

Without -fprint-explicit-foralls: (a ~ Int) => a -> T b -> a With -fprint-explicit-foralls: forall a b. (a ~ Int) => a -> T b -> a

...
:t bar @Bool

Without -fprint-explicit-foralls: (Bool ~ Int) => Bool -> T b -> Bool With -fprint-explicit-foralls: forall b. (Bool ~ Int) => Bool -> T b -> Bool

...
I guess the answer to these depends on if `b` is quantified or not.

b *is* quantified -- the quantification happens on the type as the user writes it.

Richard

...
On Fri, Mar 15, 2019 at 1:26 AM Simon Peyton Jones wrote:

...
This looks particularly confusing without the explicit `forall`, although it seems questionable either way.

Why? GHC often suppresses foralls when printing types; and had -fprint-explicit-foralls to stop doing that.

Simon

From: ghc-steering-committee On Behalf Of Richard Eisenberg Sent: 14 March 2019 23:46 To: Iavor Diatchki Cc: ghc-steering-committee@haskell.org; Joachim Breitner Subject: Re: [ghc-steering-committee] #179: Tweak the printing of foralls, recommendation: accept

...
On Mar 14, 2019, at 6:18 PM, Iavor Diatchki wrote:

bar :: forall a b. (a ~ Int) => a -> b -> a

Is it the case that `:t bar @Bool` will print

bar :: (Bool ~ Int) => Bool -> b -> Bool

This looks particularly confusing without the explicit `forall`, although it seems questionable either way.

Yes, you understand correctly. `:t bar @Bool` will print that unfortunate type. I agree this is questionable. But I don't know how to do better. The current state of affairs is awkward in a different way, in that `:t bar @Bool` errors (that's OK) and `:t bar @Int` prints `forall {b}. Int -> b -> Int`, even though a further visible type application is possible. Perhaps worse, `:t bar` today prints `forall {b}. Int -> b -> Int` even though the next variable to be instantiated is `a`. This is why we have `:type +v`.

The direction in the proposal came about in wondering if it's possible to improve the mechanics of `:t` (without the `+v`). After we thought of doing maximal instantiation of inferred arguments (but no generalization), then we realized we could drop `:type +v` as redundant. I agree it's something of an uneasy compromise here, but I think any choice is going to have unfortunate behavior in some scenarios.

Richard

...
-Iavor

On Thu, Mar 14, 2019 at 7:47 AM Joachim Breitner wrote:

...
Dear Committee,

Richard, in collarboration with Simon PJ, proposes some tweaks to how foralls are printed by GHC.

In particular, whenever a type variable is printed with an forall, it is printed with {a} unless it is a specified variable. And there are tweaks to what :type does with its argument that makes it more useful, and obviates the need for a separate :type +v. https://github.com/goldfirere/ghc-proposals/blob/printing-foralls/proposals/...

I like that it actually simplifies the UI (by removing :type +v), so I recommend acceptance.

Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEGkYIf5Vdk8V8YFcbPZCKs/D79R8FAlyKaX8ACgkQPZCKs/D7 9R/7oxAAgU213SuV+1lr/JExnMSPNWD6s7CPTWdauLK+tHYUv1MD3HeZlBZb2pvN R/swC6jdm95vKXWeMVhfYGFGepOdMEKzqBWLDf3fCO29MlHlb4barwtEZOZ9AbaM DSyE+RjVQ35ATZPvfFTYdBacBrvCivoRWcUdi10ps6rizI86gKeCiG1PN5nVMNV+ cpvTpFWRm/xmbtU4xFWuZ9FjL0bfO6yJCueX07gTkdZYW4vnvWSdis6CInkQZ7SA hXbTEYNT9zMCGvJMG+NQN+5c0h3GJlUoTsNGd0PsQnkvoYiLjM52eM5hzkz5zFRr mMYT381T1nnIl505IFGuT/je5KAn7wTImIXvvclwDxfjCBn3J1IRVAbikgwlTU4M 9L+tlQiTKI8OZpbgpPjjRj4hWrnX1gzWiIGwtPYtQuPhkDhEvq0xex8qEKpd7waE r5klTYyZrC0LGaHyX5G5yunGLWqnlLKOHAPI20Z1bxVPtDJZ/4g6AoCYSNqBLsHt fMTFflHdKTlsCOETPGhaxgf6PP0WvZtNdgTrB2rL5jzKJSOKc1rVRFAdYIr5PP3H c4aZGce/ChyFazHeF7hH5UZ7yyB0gMc3T+do6I8vySp0YGeRweb36FU13CduMS05 rvzb6GIkNFz/Fx2MascE9kZtGvDT9BlxGXqJ9rL/huXquIwN6Gg= =1qbg -----END PGP SIGNATURE----- _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Iavor Diatchki

1:15 p.m.

New subject: #179: Tweak the printing of foralls, recommendation: accept

I am fine with the change. Something that I've realized from the last few discussions we've had is that the underlying feature I find questionable is the bit where GHC infers a variable ordering from the written signatures (left to write, but kinds before types, and synonyms matter). On Wed, Apr 17, 2019 at 12:02 AM Joachim Breitner wrote:

...

Hi Iavor,

have these explanations helped your understanding here? Do they address your concerns?

Cheers, Joachim

...
On Mar 15, 2019, at 1:04 PM, Iavor Diatchki wrote:

...
This is a bit orthogonal, but what would you expect to see in this

case:

...
type T b = Bool bar :: (a ~ Int) => a -> T b -> a

:t bar

Without -fprint-explicit-foralls: (a ~ Int) => a -> T b -> a With -fprint-explicit-foralls: forall a b. (a ~ Int) => a -> T b -> a

...
:t bar @Bool

Without -fprint-explicit-foralls: (Bool ~ Int) => Bool -> T b -> Bool With -fprint-explicit-foralls: forall b. (Bool ~ Int) => Bool -> T b -> Bool

...
I guess the answer to these depends on if `b` is quantified or not.

b *is* quantified -- the quantification happens on the type as the user writes it.

Richard

...
On Fri, Mar 15, 2019 at 1:26 AM Simon Peyton Jones <

simonpj@microsoft.com> wrote:

...
...
This looks particularly confusing without the explicit `forall`, although it seems questionable either way.

Why? GHC often suppresses foralls when printing types; and had -fprint-explicit-foralls to stop doing that.

Simon

From: ghc-steering-committee < ghc-steering-committee-bounces@haskell.org> On Behalf Of Richard Eisenberg Sent: 14 March 2019 23:46 To: Iavor Diatchki Cc: ghc-steering-committee@haskell.org; Joachim Breitner < mail@joachim-breitner.de> Subject: Re: [ghc-steering-committee] #179: Tweak the printing of foralls, recommendation: accept

...
On Mar 14, 2019, at 6:18 PM, Iavor Diatchki < iavor.diatchki@gmail.com> wrote:

bar :: forall a b. (a ~ Int) => a -> b -> a

Is it the case that `:t bar @Bool` will print

bar :: (Bool ~ Int) => Bool -> b -> Bool

This looks particularly confusing without the explicit `forall`, although it seems questionable either way.

Yes, you understand correctly. `:t bar @Bool` will print that unfortunate type. I agree this is questionable. But I don't know how to do better. The current state of affairs is awkward in a different way, in that `:t bar @Bool` errors (that's OK) and `:t bar @Int` prints `forall {b}. Int -> b -> Int`, even though a further visible type application is possible. Perhaps worse, `:t bar` today prints `forall {b}. Int -> b -> Int` even

...
...
...
The direction in the proposal came about in wondering if it's

Am Freitag, den 15.03.2019, 14:03 -0400 schrieb Richard Eisenberg: though the next variable to be instantiated is `a`. This is why we have `:type +v`. possible to improve the mechanics of `:t` (without the `+v`). After we thought of doing maximal instantiation of inferred arguments (but no generalization), then we realized we could drop `:type +v` as redundant. I agree it's something of an uneasy compromise here, but I think any choice is going to have unfortunate behavior in some scenarios.

...
...
...
Richard

...
-Iavor

On Thu, Mar 14, 2019 at 7:47 AM Joachim Breitner <

mail@joachim-breitner.de> wrote:

...
...
...
Dear Committee,

Richard, in collarboration with Simon PJ, proposes some tweaks to how foralls are printed by GHC.

In particular, whenever a type variable is printed with an forall, it is printed with {a} unless it is a specified variable. And there are tweaks to what :type does with its argument that makes it more useful, and obviates the need for a separate :type +v.

https://github.com/goldfirere/ghc-proposals/blob/printing-foralls/proposals/...

...
I like that it actually simplifies the UI (by removing :type

+v), so I

...
recommend acceptance.

Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEGkYIf5Vdk8V8YFcbPZCKs/D79R8FAlyKaX8ACgkQPZCKs/D7 9R/7oxAAgU213SuV+1lr/JExnMSPNWD6s7CPTWdauLK+tHYUv1MD3HeZlBZb2pvN R/swC6jdm95vKXWeMVhfYGFGepOdMEKzqBWLDf3fCO29MlHlb4barwtEZOZ9AbaM DSyE+RjVQ35ATZPvfFTYdBacBrvCivoRWcUdi10ps6rizI86gKeCiG1PN5nVMNV+ cpvTpFWRm/xmbtU4xFWuZ9FjL0bfO6yJCueX07gTkdZYW4vnvWSdis6CInkQZ7SA hXbTEYNT9zMCGvJMG+NQN+5c0h3GJlUoTsNGd0PsQnkvoYiLjM52eM5hzkz5zFRr mMYT381T1nnIl505IFGuT/je5KAn7wTImIXvvclwDxfjCBn3J1IRVAbikgwlTU4M 9L+tlQiTKI8OZpbgpPjjRj4hWrnX1gzWiIGwtPYtQuPhkDhEvq0xex8qEKpd7waE r5klTYyZrC0LGaHyX5G5yunGLWqnlLKOHAPI20Z1bxVPtDJZ/4g6AoCYSNqBLsHt fMTFflHdKTlsCOETPGhaxgf6PP0WvZtNdgTrB2rL5jzKJSOKc1rVRFAdYIr5PP3H c4aZGce/ChyFazHeF7hH5UZ7yyB0gMc3T+do6I8vySp0YGeRweb36FU13CduMS05 rvzb6GIkNFz/Fx2MascE9kZtGvDT9BlxGXqJ9rL/huXquIwN6Gg= =1qbg -----END PGP SIGNATURE----- _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Joachim Breitner

1:27 p.m.

New subject: #179: Tweak the printing of foralls, recommendation: accept

Hi, ok, that means we have consensus. accepted. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Eric Seidel

1:44 p.m.

New subject: #179: Tweak the printing of foralls, recommendation: accept

On Wed, Apr 17, 2019, at 13:15, Iavor Diatchki wrote:

...

Something that I've realized from the last few discussions we've had is that the underlying feature I find questionable is the bit where GHC infers a variable ordering from the written signatures (left to write, but kinds before types, and synonyms matter).

I'm not super happy about that either, but I think it's the only way that TypeApplications could have been made useful without requiring a vast refactoring of haskell code to e.g. add explicit foralls. And TypeApplications is incredibly useful.

2225

Age (days ago)

2298

Last active (days ago)

List overview

Download

19 comments

8 participants

participants (8)

Eric Seidel
Iavor Diatchki
Joachim Breitner
Manuel M T Chakravarty
Richard Eisenberg
Richard Eisenberg
Simon Marlow
Simon Peyton Jones