Re: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock

8 Sep 2015

      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  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 javascript:_e(%7B%7D,'cvml','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
javascript:_e(%7B%7D,'cvml','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