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

[Simon Marlow]

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 <iavor.diatchki at gmail.com>
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 <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%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
>> 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%7C72f988bf86f141af91ab2d7cd011
>> db47%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
>>
>
> _______________________________________________
> 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/91442f4a/attachment-0001.html>