On Nov 27, 2017, at 10:32 AM, Simon Peyton Jones wrote:

I'm neutral on this. Clearly it's purely a UI issue; there is little impact on the compiler.

I'm a bit bothered not so much by knowing were one of these block-arguments /begin/ as knowing where it /ends/. But I'm not opposing.

The "ends" problem applies only to constructs that do not introduce layout (or, rather, do not end with a layout close-brace). Those that introduce layout end at the close-brace -- simple. Thus, the ending of `do`, `case`, `\case`, and `if|` (multi-way if) are fairly apparent, while `\`, `if` and `let` are not. Perhaps we could treat these separately, if end-detection is so bothersome. Actually, though, I support the proposal in its current form, including support for the hard-to-end constructs. Richard

Simon

| -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces@haskell.org] On Behalf Of Joachim Breitner | Sent: 27 November 2017 14:47 | To: ghc-steering-committee@haskell.org | Subject: [ghc-steering-committee] Proposal: BlockArguments (Shepherd: | Joachim) | | Dear committee, | | the BlockArguments (former ArgumentDo) proposal was brought before us: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fghc-proposals%2Fghc- | proposals%2Fpull%2F90&data=02%7C01%7Csimonpj%40microsoft.com%7C5002e529d3 | d145d0cd3908d535a5b7ef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63647 | 3908229182766&sdata=dwqEwkLl3ykQjs2PKWJzaV7z2UegZizNLIsf%2F%2FTD2CI%3D&re | served=0 | | I’ll shepherd this myself. | | The idea is to not require parenthesis around block syntax elements such | as lambda expressions, let bindings, if-then-else, case-of and (in | particular) do expressions. The change to the grammar to enable that is | actually a simplificiation (it removes one non-terminal, lexp). | | Variants proposed are: | * do this only for `do` in argument position, or | * do it for all blocks, but only in function argument positions. | | | I am fond of this proposal, because it allows code with less parenthesis | to be written. If Haskell was written from ground up, I believe there | would be little opposition to this setup, and maybe we would not have had | to hack higher-rank support into ($), as the idiom `runST $ do …` would | just be `runST do …`. | | Another argument in favor of it is the mentioned simplificiation of the | grammar rules. | | I am aware that reading the parenthesis-free code feels strange to many, | but I not overly worried about that: Every change feels strange, and in | this case, only code that is otherwise illegal is affected. | | Akio has indicated that he is willing to work on the implementation. | | | Therefore, I suggest that we accept this proposal. | | | Please discuss (or voice you silent agreement). | | Regards, | Joachim | | -- | Joachim Breitner | mail@joachim-breitner.de | | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach | im- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C5002e529d3d145d0c | d3908d535a5b7ef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636473908229 | 182766&sdata=xChzRShUBaqVnsFx%2BlpgjJT8zzK2qKcwUDmr%2FXPzMGM%3D&reserved= | 0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I'm also in favour. I vaguely recall this idea coming up at some point in the past - maybe the Haskell 98 discussion - so it would be interesting to know what the reason for omitting it was, but I have no idea how to search for it. My guess is it was just conservatism. Anyway, the only reason I can think of for rejection would be the potential to confuse people, but the impact of this is small. Let's ship it. Cheers Simon On 28 November 2017 at 01:23, Iavor Diatchki wrote:

Hello,

I also support this proposal, and think if we do this we should do it for all forms, not just some.

-Iavor

On Mon, Nov 27, 2017 at 1:36 PM Richard Eisenberg wrote:

...

...

On Nov 27, 2017, at 10:32 AM, Simon Peyton Jones wrote:

I'm neutral on this. Clearly it's purely a UI issue; there is little impact on the compiler.

I'm a bit bothered not so much by knowing were one of these block-arguments /begin/ as knowing where it /ends/. But I'm not opposing.

The "ends" problem applies only to constructs that do not introduce layout (or, rather, do not end with a layout close-brace). Those that introduce layout end at the close-brace -- simple. Thus, the ending of `do`, `case`, `\case`, and `if|` (multi-way if) are fairly apparent, while `\`, `if` and `let` are not. Perhaps we could treat these separately, if end-detection is so bothersome.

Actually, though, I support the proposal in its current form, including support for the hard-to-end constructs.

Richard

...

Simon

| -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces@haskell.org] On Behalf Of Joachim Breitner | Sent: 27 November 2017 14:47 | To: ghc-steering-committee@haskell.org | Subject: [ghc-steering-committee] Proposal: BlockArguments (Shepherd: | Joachim) | | Dear committee, | | the BlockArguments (former ArgumentDo) proposal was brought before us: | https://na01.safelinks.protection.outlook.com/?url=

...

| om%2Fghc-proposals%2Fghc- | proposals%2Fpull%2F90&data=02%7C01%7Csimonpj%40microsoft.com %7C5002e529d3 | d145d0cd3908d535a5b7ef%7C72f988bf86f141af91ab2d7cd011 db47%7C1%7C0%7C63647 | 3908229182766&sdata=dwqEwkLl3ykQjs2PKWJzaV7z2UegZi zNLIsf%2F%2FTD2CI%3D&re | served=0 | | I’ll shepherd this myself. | | The idea is to not require parenthesis around block syntax elements such | as lambda expressions, let bindings, if-then-else, case-of and (in | particular) do expressions. The change to the grammar to enable that is | actually a simplificiation (it removes one non-terminal, lexp). | | Variants proposed are: | * do this only for `do` in argument position, or | * do it for all blocks, but only in function argument positions. | | | I am fond of this proposal, because it allows code with less

...

| to be written. If Haskell was written from ground up, I believe there | would be little opposition to this setup, and maybe we would not have had | to hack higher-rank support into ($), as the idiom `runST $ do …` would | just be `runST do …`. | | Another argument in favor of it is the mentioned simplificiation of

https%3A%2F%2Fgithub.c parenthesis the

...

| grammar rules. | | I am aware that reading the parenthesis-free code feels strange to many, | but I not overly worried about that: Every change feels strange, and in | this case, only code that is otherwise illegal is affected. | | Akio has indicated that he is willing to work on the implementation. | | | Therefore, I suggest that we accept this proposal. | | | Please discuss (or voice you silent agreement). | | Regards, | Joachim | | -- | Joachim Breitner | mail@joachim-breitner.de | | https://na01.safelinks.protection.outlook.com/?url= http%3A%2F%2Fwww.joach | im- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com% 7C5002e529d3d145d0c | d3908d535a5b7ef%7C72f988bf86f141af91ab2d7cd011 db47%7C1%7C0%7C636473908229 | 182766&sdata=xChzRShUBaqVnsFx%2BlpgjJT8zzK2qKcwUDmr% 2FXPzMGM%3D&reserved= | 0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@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