<div dir="ltr">A few more things to add to this discussion:<div><br></div><div>1. In terms of impact, I think it makes sense to view this extension as similar to -XDoAndIfThenElse and -XLambdaCase. Both are similar in their levels of complexity and add a similar amount of syntax. Would GHC be better off without them? Or do we expect that some future version of GHC may have one or both of them on by default? I think that if we <i>ever</i> want to change basic Haskell syntax (such as DoAndIfThenElse and ArgumentBlock), we have to start it off with an extension. </div><div><br></div><div>2. Following up on that, perhaps another way to view this question is: Do we ever want this functionality to be part of standard Haskell? If not, then I would vote against this extension, because it just adds fragmentation. If there's a possibility that we may want to permanently change default syntax a la ArgumentBlock, then we have to start off with an extension. (FYI I believe it is a valid possibility, in that the extension is inherently backwards compatible -- it should not break any code if it is enabled, as it allows strictly more parses.)</div><div><br></div><div>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.) </div><div><div><br></div><div>4. We can easily generalize this to include case, let, and so on. It was written without support for them to limit the scope of the change, rather than because it is not possible.</div></div><div><br></div><div>As an aside, my favorite comment so far is "All this because Haskellers are allergic to parentheses ~chrisdone".</div><div><br></div><div>-- Andrew Gibiansky</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 6, 2015 at 11:17 AM, Amos Robinson <span dir="ltr"><<a href="mailto:amos.robinson@gmail.com" target="_blank">amos.robinson@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If you made tooling aware of ($) would you need to check that it is importing the Prelude version and not another one? Not that I'm suggesting that having a different implementation would be sensible.<br><br>This seems rather good to me. It seems sensible and I don't really see the ambiguity.<div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Sun, 6 Sep 2015 at 11:11 Tom Ellis <<a href="mailto:tom-lists-haskell-cafe-2013@jaguarpaw.co.uk" target="_blank">tom-lists-haskell-cafe-2013@jaguarpaw.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Sep 06, 2015 at 06:03:00PM +0000, Oliver Charles wrote:<br>
> I mean that people us $ for purely syntactical purposes. If an editor is<br>
> going to make refactorings and retain a certain sense of style, then the<br>
> tool needs to know that $ is sometimes to be used. The refactoring (or<br>
> otherwise) tool now has to be aware of the syntax of Haskell and special<br>
> symbols in the Prelude.<br>
<br>
It seems unlikely that making the tool aware of ($) is much more (or less)<br>
difficult than making it aware of when it can omit brackets from a multiline<br>
do, lambda etc.<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>
</blockquote></div>
</div></div><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>