[Haskell-cafe] GHC Extension Proposal: ArgumentBlock

[Andrew Gibiansky]

A few more things to add to this discussion:

1. In terms of impact, I think it makes sense to view this extension as
similar to -XDoAndIfThenElse and -XLambdaCase. Both are similar in their
levels of complexity and add a similar amount of syntax. Would GHC be
better off without them? Or do we expect that some future version of GHC
may have one or both of them on by default? I think that if we *ever* want
to change basic Haskell syntax (such as DoAndIfThenElse and ArgumentBlock),
we have to start it off with an extension.

2. Following up on that, perhaps another way to view this question is: Do
we ever want this functionality to be part of standard Haskell? If not,
then I would vote against this extension, because it just adds
fragmentation. If there's a possibility that we may want to permanently
change default syntax a la ArgumentBlock, then we have to start off with an
extension. (FYI I believe it is a valid possibility, in that the extension
is inherently backwards compatible -- it should not break any code if it is
enabled, as it allows strictly more parses.)

3. It does make some cases cleaner. Consider the following code: [1, 2, 3]
++ concat (do { .... }). This can be written with parentheses, bit it
cannot be written with $, because [1, 2, 3] ++ concat $ do { .... } would
parse as ([1, 2, 3] ++ concat) $ do { ... }. This is sometimes annoying
behaviour. (I used the list monad here just for demo purposes. I find it is
more common with applicative operators.)

4. We can easily generalize this to include case, let, and so on. It was
written without support for them to limit the scope of the change, rather
than because it is not possible.

As an aside, my favorite comment so far is "All this because Haskellers are
allergic to parentheses ~chrisdone".

-- Andrew Gibiansky

On Sun, Sep 6, 2015 at 11:17 AM, Amos Robinson <amos.robinson at gmail.com>
wrote:

> If you made tooling aware of ($) would you need to check that it is
> importing the Prelude version and not another one? Not that I'm suggesting
> that having a different implementation would be sensible.
>
> This seems rather good to me. It seems sensible and I don't really see the
> ambiguity.
>
> On Sun, 6 Sep 2015 at 11:11 Tom Ellis <
> tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:
>
>> On Sun, Sep 06, 2015 at 06:03:00PM +0000, Oliver Charles wrote:
>> > 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.
>>
>> It seems unlikely that making the tool aware of ($) is much more (or less)
>> difficult than making it aware of when it can omit brackets from a
>> multiline
>> do, lambda etc.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
> _______________________________________________
> 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/20150906/c48ad214/attachment.html>