foo (bar (baz (qux (quux (do a <- b; return a)))))

Using function composition:

    (foo . bar . baz . qux . quux) (do a <- b; return a)
    (foo . bar . baz . qux . quux) do
      a <- b
      return a

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.

foo (bar baz) (qux quux) (do
  a <- b
  return a) -- ugh this close paren

foo (bar baz) (qux quux) do
  a <- b
  return a
  -- much nicer, "do" feels like the comparable Ruby keyword

The usage of $ to accomplish this is a hack that Haskellers have gotten very accustomed to. It frequently trips up the uninitiated. It requires a hack in the compiler when used with ST blocks.

On Tuesday, September 8, 2015, Alexey Vagarenko <vagarenko@gmail.com> wrote:
Consider this.
If we didn't have $ operator in the first place, we'd use parentheses everywhere:

    foo (bar (baz (qux (quux (do a <- b; return a)))))
under your proposal it turns to:
    foo (bar (baz (qux (quux do a <- b; return a))))

another example:
    foo (bar baz) (qux quux) (do a <- b; return a)
turns to :
    foo (bar baz) (qux quux) do a <- b; return a

with lambdas:
    foo (bar baz) (qux quux) (\x -> x)
to:
    foo (bar baz) (qux quux) \x -> x

Can't you see your proposal makes things less consistent, not more?
-1.

2015-09-07 0:03 GMT+06:00 Oliver Charles <ollie@ocharles.org.uk>:
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.

On Sun, Sep 6, 2015 at 6:53 PM Matthew Pickering <matthewtpickering@gmail.com> wrote:
>
> I don't really like $ from an editor perspective though (tooling has to
> become aware of a single function when performing refactorings), so anything
> that helps reduce how prolific that operator is is a win in my book!
>

Can you please explain what you mean by this? Is there something more
subtle that $ being a low fixity operator? Which specific problems
does it cause tooling? Are you referring to the fact that there are
problems because $ == id and makes tooling account for two cases when
looking for refactorings? (I'm thinking of hlint here).

(FWIW, haskell-src-exts tries to fiddle with the AST to account for
fixity after parsing but the GHC parser does not, it happens during
renaming. There is a pure version here[1] if anyone else is in need of
this feature).

Thanks, Matt



--
-- Dan Burton