[Haskell-cafe] GHC Extension Proposal: ArgumentBlock

[Andrew Gibiansky]

So, it looks like this extension is quite controversial. To summarize the
main points raised in this discussion:

Pro: (+9)
    - It's easier to read than the alternative.
    - This extension removes syntactic noise.
    - This makes basic do-syntax more approachable to newbies; it is a
commonly asked question as to why the $ is necessary.
    - This simplifies the resulting AST, potentially making it simpler for
editors and other tools to do refactoring.
    - It's something that belongs in the main language, and if its
something we'd consider for a mythical Haskell', it has to start as an
extension.
    - It gets rid of some cases where using $ doesn't work because $
interacts with other infix operators being used in the same expression.
    - This would make do blocks consistent with record creation, where
parentheses are skipped, allowing things such as "return R { x = y}"
    - This does not change the meaning of any old programs, only allows new
ones that were previously forbidden.
    - This gets rid of the need for a specially-typed $ allowing "runSt $
do ..."

Con: (-9)
    - It's harder to read than the alternative.
    - Creating a language extension to get rid of a single character is
overkill and unnecessary.
    - You can already get rid of the $ by just adding parentheses.
    - More and more syntactic "improvements" just fragment the language.
    - Although this is consistent with record syntax, record syntax without
parents was a mistake originally.

Questions:
    - Why doesn't this apply to case, let, if, etc?
    - Should this apply to case, let, if, etc?

I would say people on /r/haskell and haskell-cafe seem fairly evenly split,
perhaps somewhat favoring *not* including this extension.

1. How representative are the opinions expressed through these media of the
general Haskell community? (If one exists...)
2. What, historically, has been the GHC policy on including
questionable/controversial extensions?
3. We do have another option: with the advent of ghc-exactprint, we could
probably write a preprocessor that emulates this extension, parsing as if
ArgumentDo is enabled and then inserting a $ where necessary. This would
allow us to test out this extension without modifying GHC and thus being
stuck with the extension in mainline GHC indefinitely (since, as I
understand it, there's not really a process for *removing* extensions from
GHC).


On Mon, Sep 7, 2015 at 5:10 AM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Sonntag, den 06.09.2015, 11:28 -0700 schrieb Andrew Gibiansky:
> > 3. It does make some cases cleaner. Consider the following code: [1,
> > 2, 3] ++ concat (do { .... }). This can be written with parentheses,
> > bit it cannot be written with $, because [1, 2, 3] ++ concat $ do {
> > .... } would parse as ([1, 2, 3] ++ concat) $ do { ... }. This is
> > sometimes annoying behaviour. (I used the list monad here just for
> > demo purposes. I find it is more common with applicative operators.)
>
> good point! This has bitten me before.
>
> I believe that the language would be better with the proposed syntax
> change being the default. So the way forward is to indeed add this
> extension, see how people use it, and if Haskell' ever goes somewhere,
> it might include this as the default – all alike to DoAndIfThenElse.
>
> Also note that this does not change the meaning of any existing
> program, AFAIK. So it is not that you might be reading existing code
> wrongly if you are not aware that this extension is being used; you
> will just find code that looks like invalid syntax to you – until you
> check the list of extensions (or just deduce that ArgumentBlock is used
> here).
>
> Therefore, +1 from me.
>
> Greetings,
> Joachim
>
> --
> Joachim “nomeata” Breitner
>   mail at joachim-breitner.de • http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/08a86b50/attachment.html>