[Haskell-cafe] GHC Extension Proposal: ArgumentBlock

Oliver Batchelor saulzar at gmail.com
Wed Sep 9 02:30:55 UTC 2015

All of those examples look like good reasons to support the proposal to me.

I'm +1 on this for the simple reason that it takes an established practice
and removes syntactic noise. Is there an example where it actually adds
extra syntactic noise?

Oliver Batchelor

On Wed, Sep 9, 2015 at 12:36 AM, Alexey Vagarenko <vagarenko at gmail.com>

> 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>:
>> 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> 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
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150909/42c1987c/attachment.html>

More information about the Haskell-Cafe mailing list