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

[Iavor Diatchki]

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 <rae at cs.brynmawr.edu>
wrote:

>
> > 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
>
> _______________________________________________
> 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: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20171128/eb563715/attachment.html>