[ghc-steering-committee] Proposal: BlockArguments (Shepherd: Joachim)

Richard Eisenberg rae at cs.brynmawr.edu
Mon Nov 27 21:36:26 UTC 2017


> On Nov 27, 2017, at 10:32 AM, Simon Peyton Jones <simonpj at microsoft.com> 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 at haskell.org] On Behalf Of Joachim Breitner
> | Sent: 27 November 2017 14:47
> | To: ghc-steering-committee at 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 at 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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee



More information about the ghc-steering-committee mailing list