<div dir="ltr">Hello,<div><br></div><div>I also support this proposal, and think if we do this we should do it for all forms, not just some.</div><div><br></div><div>-Iavor</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 27, 2017 at 1:36 PM Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu">rae@cs.brynmawr.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Nov 27, 2017, at 10:32 AM, Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> wrote:<br>
><br>
> I'm neutral on this.  Clearly it's purely a UI issue; there is little impact on the compiler.<br>
><br>
> 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.<br>
<br>
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.<br>
<br>
Actually, though, I support the proposal in its current form, including support for the hard-to-end constructs.<br>
<br>
Richard<br>
<br>
><br>
> Simon<br>
><br>
> | -----Original Message-----<br>
> | From: ghc-steering-committee [mailto:<a href="mailto:ghc-steering-committee-" target="_blank">ghc-steering-committee-</a><br>
> | <a href="mailto:bounces@haskell.org" target="_blank">bounces@haskell.org</a>] On Behalf Of Joachim Breitner<br>
> | Sent: 27 November 2017 14:47<br>
> | To: <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> | Subject: [ghc-steering-committee] Proposal: BlockArguments (Shepherd:<br>
> | Joachim)<br>
> |<br>
> | Dear committee,<br>
> |<br>
> | the BlockArguments (former ArgumentDo) proposal was brought before us:<br>
> | <a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c" rel="noreferrer" target="_blank">https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c</a><br>
> | om%2Fghc-proposals%2Fghc-<br>
> | proposals%2Fpull%2F90&data=02%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer" target="_blank">40microsoft.com</a>%7C5002e529d3<br>
> | d145d0cd3908d535a5b7ef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63647<br>
> | 3908229182766&sdata=dwqEwkLl3ykQjs2PKWJzaV7z2UegZizNLIsf%2F%2FTD2CI%3D&re<br>
> | served=0<br>
> |<br>
> | I’ll shepherd this myself.<br>
> |<br>
> | The idea is to not require parenthesis around block syntax elements such<br>
> | as lambda expressions, let bindings, if-then-else, case-of and (in<br>
> | particular) do expressions. The change to the grammar to enable that is<br>
> | actually a simplificiation (it removes one non-terminal, lexp).<br>
> |<br>
> | Variants proposed are:<br>
> |  * do this only for `do` in argument position, or<br>
> |  * do it for all blocks, but only in function argument positions.<br>
> |<br>
> |<br>
> | I am fond of this proposal, because it allows code with less parenthesis<br>
> | to be written. If Haskell was written from ground up, I believe there<br>
> | would be little opposition to this setup, and maybe we would not have had<br>
> | to hack higher-rank support into ($), as the idiom `runST $ do …` would<br>
> | just be `runST do …`.<br>
> |<br>
> | Another argument in favor of it is the mentioned simplificiation of the<br>
> | grammar rules.<br>
> |<br>
> | I am aware that reading the parenthesis-free code feels strange to many,<br>
> | but I not overly worried about that: Every change feels strange, and in<br>
> | this case, only code that is otherwise illegal is affected.<br>
> |<br>
> | Akio has indicated that he is willing to work on the implementation.<br>
> |<br>
> |<br>
> | Therefore, I suggest that we accept this proposal.<br>
> |<br>
> |<br>
> | Please discuss (or voice you silent agreement).<br>
> |<br>
> | Regards,<br>
> | Joachim<br>
> |<br>
> | --<br>
> | Joachim Breitner<br>
> |   <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
> |<br>
> | <a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach" rel="noreferrer" target="_blank">https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach</a><br>
> | im-<br>
> | <a href="http://breitner.de" rel="noreferrer" target="_blank">breitner.de</a>%2F&data=02%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer" target="_blank">40microsoft.com</a>%7C5002e529d3d145d0c<br>
> | d3908d535a5b7ef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636473908229<br>
> | 182766&sdata=xChzRShUBaqVnsFx%2BlpgjJT8zzK2qKcwUDmr%2FXPzMGM%3D&reserved=<br>
> | 0<br>
> _______________________________________________<br>
> ghc-steering-committee mailing list<br>
> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>