<font size="2"><span style="background-color:rgba(255,255,255,0)"> foo (bar (baz (qux (quux (do a <- b; return a)))))</span></font><div><font size="2"><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);"><br></span></font></div><div><font size="2"><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);">Using function composition:</span></font></div><div><font size="2"><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);"><br></span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> (foo . bar . baz . qux . quux) (do a <- b; return a)</span></font><br></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> (foo . bar . baz . qux . quux) do</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> a <- b</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> return a</span></font></div><div><br></div><div>Here's why I like the proposed extension, especially in a world without $. It is because it enables intuitive multiline Haskell code with significant white space rather than parens.</div><div><br></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">foo (bar baz) (qux quux) (do</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> a <- b</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> return a) -- ugh this close paren</span></font><br></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">foo (bar baz) (qux quux) do</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> a <- b</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> return a</span></font></div></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> -- much nicer, "do" feels like the comparable Ruby keyword</span></font></div><div><br></div><div>The usage of $ to accomplish this is a hack that Haskellers have gotten very accustomed to. It frequently trips up the uninitiated<span></span>. It requires a hack in the compiler when used with ST blocks.</div><div><br>On Tuesday, September 8, 2015, Alexey Vagarenko <<a href="mailto:vagarenko@gmail.com">vagarenko@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Consider this.<br>If we didn't have $ operator in the first place, we'd use parentheses everywhere:<br><br><span style="font-family:monospace,monospace"> foo (bar (baz (qux (quux (do a <- b; return a)))))</span><br>under your proposal it turns to:<br><span style="font-family:monospace,monospace"> foo (bar (baz (qux (quux do a <- b; return a))))</span><br><br>another example:<br><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace"> </span>foo (bar baz) (qux quux) (do a <- b; return a)</span><br>turns to :<br><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace"> </span>foo (bar baz) (qux quux) do a <- b; return a</span><br><br>with lambdas:<br><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace"> </span>foo (bar baz) (qux quux) (\x -> x)</span><br>to:<br><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace"> </span>foo (bar baz) (qux quux) \x -> x</span><br><br>Can't you see your proposal makes things <b>less </b>consistent, <b>not more</b>?<br>-1.</div><div class="gmail_extra"><br><div class="gmail_quote">2015-09-07 0:03 GMT+06:00 Oliver Charles <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','ollie@ocharles.org.uk');" target="_blank">ollie@ocharles.org.uk</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I mean that people us $ for purely syntactical purposes. If an editor is going to make refactorings and retain a certain sense of style, then the tool needs to know that $ is sometimes to be used. The refactoring (or otherwise) tool now has to be aware of the syntax of Haskell and special symbols in the Prelude.</div><div><div><br><div class="gmail_quote"><div dir="ltr">On Sun, Sep 6, 2015 at 6:53 PM Matthew Pickering <<a href="javascript:_e(%7B%7D,'cvml','matthewtpickering@gmail.com');" target="_blank">matthewtpickering@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">><br>
> I don't really like $ from an editor perspective though (tooling has to<br>
> become aware of a single function when performing refactorings), so anything<br>
> that helps reduce how prolific that operator is is a win in my book!<br>
><br>
<br>
Can you please explain what you mean by this? Is there something more<br>
subtle that $ being a low fixity operator? Which specific problems<br>
does it cause tooling? Are you referring to the fact that there are<br>
problems because $ == id and makes tooling account for two cases when<br>
looking for refactorings? (I'm thinking of hlint here).<br>
<br>
(FWIW, haskell-src-exts tries to fiddle with the AST to account for<br>
fixity after parsing but the GHC parser does not, it happens during<br>
renaming. There is a pure version here[1] if anyone else is in need of<br>
this feature).<br>
<br>
Thanks, Matt<br>
</blockquote></div>
</div></div></blockquote></div><br></div>
</blockquote></div><br><br>-- <br>-- Dan Burton<br>