[Haskell-cafe] GHC Extension Proposal: ArgumentBlock

[Dan Burton]

    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 at 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 at ocharles.org.uk
> <javascript:_e(%7B%7D,'cvml','ollie at 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 at gmail.com
>> <javascript:_e(%7B%7D,'cvml','matthewtpickering at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/f441ff10/attachment.html>