<div dir="ltr"><div>So, it looks like this extension is quite controversial. To summarize the main points raised in this discussion:</div><div><br></div><div>Pro: (+9)</div><div>    - It's easier to read than the alternative.</div><div>    - This extension removes syntactic noise.</div><div>    - This makes basic do-syntax more approachable to newbies; it is a commonly asked question as to why the $ is necessary.</div><div>    - This simplifies the resulting AST, potentially making it simpler for editors and other tools to do refactoring.</div><div>    - 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.</div><div>    - It gets rid of some cases where using $ doesn't work because $ interacts with other infix operators being used in the same expression.</div><div>    - This would make do blocks consistent with record creation, where parentheses are skipped, allowing things such as "return R { x = y}"</div><div>    - This does not change the meaning of any old programs, only allows new ones that were previously forbidden.</div><div>    - This gets rid of the need for a specially-typed $ allowing "runSt $ do ..."</div><div><br></div><div>Con: (-9)</div><div>    - It's harder to read than the alternative.</div><div>    - Creating a language extension to get rid of a single character is overkill and unnecessary.</div><div>    - You can already get rid of the $ by just adding parentheses.</div><div>    - More and more syntactic "improvements" just fragment the language.</div><div>    - Although this is consistent with record syntax, record syntax without parents was a mistake originally.</div><div><br></div><div>Questions:</div><div>    - Why doesn't this apply to case, let, if, etc?</div><div>    - Should this apply to case, let, if, etc?</div><div><br></div><div>I would say people on /r/haskell and haskell-cafe seem fairly evenly split, perhaps somewhat favoring *not* including this extension. </div><div><br></div><div>1. How representative are the opinions expressed through these media of the general Haskell community? (If one exists...)</div><div>2. What, historically, has been the GHC policy on including questionable/controversial extensions?</div><div>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).</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 7, 2015 at 5:10 AM, Joachim Breitner <span dir="ltr"><<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
Am Sonntag, den 06.09.2015, 11:28 -0700 schrieb Andrew Gibiansky:<br>
> 3. It does make some cases cleaner. Consider the following code: [1,<br>
> 2, 3] ++ concat (do { .... }). This can be written with parentheses,<br>
> bit it cannot be written with $, because [1, 2, 3] ++ concat $ do {<br>
> .... } would parse as ([1, 2, 3] ++ concat) $ do { ... }. This is<br>
> sometimes annoying behaviour. (I used the list monad here just for<br>
> demo purposes. I find it is more common with applicative operators.)<br>
<br>
</span>good point! This has bitten me before.<br>
<br>
I believe that the language would be better with the proposed syntax<br>
change being the default. So the way forward is to indeed add this<br>
extension, see how people use it, and if Haskell' ever goes somewhere,<br>
it might include this as the default – all alike to DoAndIfThenElse.<br>
<br>
Also note that this does not change the meaning of any existing<br>
program, AFAIK. So it is not that you might be reading existing code<br>
wrongly if you are not aware that this extension is being used; you<br>
will just find code that looks like invalid syntax to you – until you<br>
check the list of extensions (or just deduce that ArgumentBlock is used<br>
here).<br>
<br>
Therefore, +1 from me.<br>
<br>
Greetings,<br>
Joachim<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Joachim “nomeata” Breitner<br>
  <a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a> • <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
  Jabber: <a href="mailto:nomeata@joachim-breitner.de">nomeata@joachim-breitner.de</a>  • GPG-Key: 0xF0FBF51F<br>
  Debian Developer: <a href="mailto:nomeata@debian.org">nomeata@debian.org</a><br>
</font></span><br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div>