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