<div dir="ltr">I don't think you need ghc-exactprint for that - you can just write a GHC preprocessor, hopefully being able to reuse the current grammar specification you already have. See the -prgmF option (I think it's called that, best check the GHC manual). You don't really care about the source code formatting, because you're going to pass it straight off to the compiler anyway. Though I guess maybe exactprint could help so error messages still map cleanly.</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 7, 2015 at 6:57 PM Andrew Gibiansky <<a href="mailto:andrew.gibiansky@gmail.com">andrew.gibiansky@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><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><font color="#888888"><br>
--<br>
Joachim “nomeata” Breitner<br>
<a href="mailto:mail@joachim-breitner.de" target="_blank">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" target="_blank">nomeata@joachim-breitner.de</a> • GPG-Key: 0xF0FBF51F<br>
Debian Developer: <a href="mailto:nomeata@debian.org" target="_blank">nomeata@debian.org</a><br>
</font></span><br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">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>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">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>
</blockquote></div>