GHC Extension Proposal: ArgumentBlock

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
75 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

GHC Extension Proposal: ArgumentBlock

Andrew Gibiansky
I'd like to propose a GHC extension called (for now) `ArgumentBody`. `ArgumentBody` is a simple syntax extension, than, when enabled, permits the following code:

main = when True do
  putStrLn "Hello!"

main = forM values \value ->
  print value

main = forM values \case
    Just x -> print x
    Nothing -> print y

In this code we do not need `$` before `do`, lambda, or lambda-case (if -XLambdaCase is enabled). This change would not extend to `let`, `if`, `case`, or any other constructs.

Pros:

1. Code is simpler and it greatly reduces the need for "operator line noise" of $ everywhere.
2. We can avoid using the type-checker hack for $ for things such as runSt.

Cons:

1. Adds complexity to the compiler. (NB: The change is minimal and not invasive at all.)
2. Contributes to a proliferation of extensions that other tools must support.  (NB: This is just a parser change so should be easy for all tools to support.)

I'm very interested in hearing both favoring and dissenting opinions on this proposed change. If this change is approved of, names besides -XArgumentBody can be considered.

See more info on Trac.

-- Andrew Gibiansky

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extension Proposal: ArgumentBlock

Will Yager
+1. I have often wanted this feature. Not only does it remove syntactic noise, but it makes basic do-syntax much more approachable for newbies.

--Will


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extension Proposal: ArgumentBlock

Alexey Vagarenko
In reply to this post by Andrew Gibiansky
-1.
Creating a language extension just to get rid of a single character is overkill.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extension Proposal: ArgumentBlock

Oliver Charles-3
I'm loosely in favour of this for 'do', not quite so keen for lambda expressions - but I have no justifiable reason why, other than "it looks a bit weird".

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!

Is the following going to be valid code under your extension?

   runReaderT
     do foo
        bar
     env

Likewise, I expect the following also parses:

import Control.Monad

main :: IO ()
main = when True
         do print "Hello"

- Ollie 

On Sun, Sep 6, 2015 at 7:17 AM Alexey Vagarenko <[hidden email]> wrote:
-1.
Creating a language extension just to get rid of a single character is overkill.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extension Proposal: ArgumentBlock

Bardur Arantsson-2
In reply to this post by Andrew Gibiansky
On 09/06/2015 12:55 AM, Andrew Gibiansky wrote:
> I'd like to propose a GHC extension called (for now) `ArgumentBody`.
> `ArgumentBody` is a simple syntax extension, than, when enabled, permits
> the following code:
>

-1, too little gain for Yet Another Extension.

It also reduces "regularity".

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extension Proposal: ArgumentBlock

David Kraeutmann
-1, doesn't add anything useful other than saving a character.
Besides, I don't like how those snippets look without $. Seems off to
me.

On Sun, Sep 6, 2015 at 8:57 AM, Bardur Arantsson <[hidden email]> wrote:

> On 09/06/2015 12:55 AM, Andrew Gibiansky wrote:
>> I'd like to propose a GHC extension called (for now) `ArgumentBody`.
>> `ArgumentBody` is a simple syntax extension, than, when enabled, permits
>> the following code:
>>
>
> -1, too little gain for Yet Another Extension.
>
> It also reduces "regularity".
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extension Proposal: ArgumentBlock

Oliver Charles-3
People saying "it just saves a character" seems to have completely missed my point and source code readability/refactoring options from a tool's perspective. It does more than save a character.

On Sun, Sep 6, 2015 at 1:32 PM David Kraeutmann <[hidden email]> wrote:
-1, doesn't add anything useful other than saving a character.
Besides, I don't like how those snippets look without $. Seems off to
me.

On Sun, Sep 6, 2015 at 8:57 AM, Bardur Arantsson <[hidden email]> wrote:
> On 09/06/2015 12:55 AM, Andrew Gibiansky wrote:
>> I'd like to propose a GHC extension called (for now) `ArgumentBody`.
>> `ArgumentBody` is a simple syntax extension, than, when enabled, permits
>> the following code:
>>
>
> -1, too little gain for Yet Another Extension.
>
> It also reduces "regularity".
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extension Proposal: ArgumentBlock

Tom Ellis
On Sun, Sep 06, 2015 at 12:34:55PM +0000, Oliver Charles wrote:
> People saying "it just saves a character" seems to have completely missed
> my point and source code readability/refactoring options from a tool's
> perspective. It does more than save a character.

Let's look at it from the opposite direction.  If "ArgumentBlock" were
already the default then we could remove complexity from the grammar for the
cost of a single character.  That sounds like a great tradeoff to me, and is
the reason I can't support ArgumentBlock.

Tom
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extension Proposal: ArgumentBlock

Ivan Lazar Miljenovic
-1 for me, as I think the examples make it look *more* ambiguous.

Whilst it can be a pain to have to remember to add the $, there's less
immediate information that the `do`, lambdas, etc. form a new block
and are not just individual word arguments to the calling function.

On 6 September 2015 at 22:45, Tom Ellis
<[hidden email]> wrote:

> On Sun, Sep 06, 2015 at 12:34:55PM +0000, Oliver Charles wrote:
>> People saying "it just saves a character" seems to have completely missed
>> my point and source code readability/refactoring options from a tool's
>> perspective. It does more than save a character.
>
> Let's look at it from the opposite direction.  If "ArgumentBlock" were
> already the default then we could remove complexity from the grammar for the
> cost of a single character.  That sounds like a great tradeoff to me, and is
> the reason I can't support ArgumentBlock.
>
> Tom
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe



--
Ivan Lazar Miljenovic
[hidden email]
http://IvanMiljenovic.wordpress.com
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extension Proposal: ArgumentBlock

Oliver Charles-3
In reply to this post by Tom Ellis
On Sun, Sep 6, 2015 at 1:46 PM Tom Ellis <[hidden email]> wrote:
On Sun, Sep 06, 2015 at 12:34:55PM +0000, Oliver Charles wrote:
> People saying "it just saves a character" seems to have completely missed
> my point and source code readability/refactoring options from a tool's
> perspective. It does more than save a character.

Let's look at it from the opposite direction.  If "ArgumentBlock" were
already the default then we could remove complexity from the grammar for the
cost of a single character.  That sounds like a great tradeoff to me, and is
the reason I can't support ArgumentBlock.

Really? You would rather increase syntactic complexity just to make the parser code simpler?

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extension Proposal: ArgumentBlock

Tom Ellis
In reply to this post by Andrew Gibiansky
On Sat, Sep 05, 2015 at 03:55:37PM -0700, Andrew Gibiansky wrote:

> I'd like to propose a GHC extension called (for now) `ArgumentBody`.
> `ArgumentBody` is a simple syntax extension, than, when enabled, permits
> the following code:
>
> main = when True do
>   putStrLn "Hello!"
>
>
> main = forM values \value ->
>   print value
>
>
> main = forM values \case
>     Just x -> print x
>     Nothing -> print y

By the way, you can already do

main = when True (do
  putStrLn "Hello!")


main = forM values (\value ->
  print value)


main = forM values (\case
    Just x -> print x
    Nothing -> print y)

which gets you a lot of the way, and is arguably even clearer.  This is as
style that has been promoted by Chris Done.

Tom
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extension Proposal: ArgumentBlock

Tom Ellis
In reply to this post by Oliver Charles-3
On Sun, Sep 06, 2015 at 12:52:04PM +0000, Oliver Charles wrote:

> On Sun, Sep 6, 2015 at 1:46 PM Tom Ellis <
> [hidden email]> wrote:
>
> > On Sun, Sep 06, 2015 at 12:34:55PM +0000, Oliver Charles wrote:
> > > People saying "it just saves a character" seems to have completely missed
> > > my point and source code readability/refactoring options from a tool's
> > > perspective. It does more than save a character.
> >
> > Let's look at it from the opposite direction.  If "ArgumentBlock" were
> > already the default then we could remove complexity from the grammar for
> > the
> > cost of a single character.  That sounds like a great tradeoff to me, and
> > is
> > the reason I can't support ArgumentBlock.
>
> Really? You would rather increase syntactic complexity just to make the
> parser code simpler?

On the contrary, I consider it a *decrease* in syntactic complexity!
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extension Proposal: ArgumentBlock

Tom Ellis
On Sun, Sep 06, 2015 at 01:53:44PM +0100, Tom Ellis wrote:

> On Sun, Sep 06, 2015 at 12:52:04PM +0000, Oliver Charles wrote:
> > On Sun, Sep 6, 2015 at 1:46 PM Tom Ellis <
> > [hidden email]> wrote:
> >
> > > On Sun, Sep 06, 2015 at 12:34:55PM +0000, Oliver Charles wrote:
> > > > People saying "it just saves a character" seems to have completely missed
> > > > my point and source code readability/refactoring options from a tool's
> > > > perspective. It does more than save a character.
> > >
> > > Let's look at it from the opposite direction.  If "ArgumentBlock" were
> > > already the default then we could remove complexity from the grammar for
> > > the
> > > cost of a single character.  That sounds like a great tradeoff to me, and
> > > is
> > > the reason I can't support ArgumentBlock.
> >
> > Really? You would rather increase syntactic complexity just to make the
> > parser code simpler?
>
> On the contrary, I consider it a *decrease* in syntactic complexity!

It's nothing to do with the "parser code", by the way.  It's to minimize
what I have to keep in my own head when writing code.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extension Proposal: ArgumentBlock

David Kraeutmann
In reply to this post by Tom Ellis
It's not something that belongs in an extension. Rather, it should be
in the main language.

Let's say you want to write f (\x -> x) (\y -> y) and forget the parentheses.

How would you parse the following under ArgumentBlock:
f \x -> x \y -> y?


On Sun, Sep 6, 2015 at 2:45 PM, Tom Ellis
<[hidden email]> wrote:

> On Sun, Sep 06, 2015 at 12:34:55PM +0000, Oliver Charles wrote:
>> People saying "it just saves a character" seems to have completely missed
>> my point and source code readability/refactoring options from a tool's
>> perspective. It does more than save a character.
>
> Let's look at it from the opposite direction.  If "ArgumentBlock" were
> already the default then we could remove complexity from the grammar for the
> cost of a single character.  That sounds like a great tradeoff to me, and is
> the reason I can't support ArgumentBlock.
>
> Tom
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extension Proposal: ArgumentBlock

Andrew Morris
As `f (\x -> x (\y -> y))`.

FWIW, I actually think it strange that these constructs are allowed as an argument to an infix function but not a nonfix one. So it seems to me that it would be _removing_ a weird exception rather than adding one. Assuming we add `let`, `case`, and the other things that can also be an argument to an infix op, that is. (Why are they being excluded, by the way?)

> On 6 Sep 2015, at 14:03, David Kraeutmann <[hidden email]> wrote:
>
> It's not something that belongs in an extension. Rather, it should be
> in the main language.
>
> Let's say you want to write f (\x -> x) (\y -> y) and forget the parentheses.
>
> How would you parse the following under ArgumentBlock:
> f \x -> x \y -> y?
>
>
> On Sun, Sep 6, 2015 at 2:45 PM, Tom Ellis
> <[hidden email]> wrote:
>> On Sun, Sep 06, 2015 at 12:34:55PM +0000, Oliver Charles wrote:
>>> People saying "it just saves a character" seems to have completely missed
>>> my point and source code readability/refactoring options from a tool's
>>> perspective. It does more than save a character.
>>
>> Let's look at it from the opposite direction.  If "ArgumentBlock" were
>> already the default then we could remove complexity from the grammar for the
>> cost of a single character.  That sounds like a great tradeoff to me, and is
>> the reason I can't support ArgumentBlock.
>>
>> Tom
>> _______________________________________________
>> Haskell-Cafe mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extension Proposal: ArgumentBlock

Sven Panne-2
In reply to this post by Oliver Charles-3
2015-09-06 14:34 GMT+02:00 Oliver Charles <[hidden email]>:
People saying "it just saves a character" seems to have completely missed my point and source code readability/refactoring options from a tool's perspective. It does more than save a character.

Could you elaborate on the "refactoring options"? I don't fully understand why requiring $ makes things *more* complicated for a tool. It seems to me that introducing another irregularity (leaving out $) makes a tool's life harder, not easier.

Regarding readability: This is a totally subjective thing, e.g. for me all the examples without the $ look really, really horrible and confusing. To me, the $ is a strong visual clue for "here comes an argument" which is lost under the proposal. The point that there is no possible valid parse without it is irrelevant IMHO: Programs are mainly meant to be read by humans, not computers. Try parsing

  foo bar do baz boo do skooby doo

visually and compare that to the version with $.


Furthermore, I fully agree with others that introducing another syntactic irregularity is bad from an aesthetic point of view. To make things worse, the irregularity itself is itself, well, irregular by leaving out let/if/case/...

And finally: There seems to be a trend recently to propose minor syntactic "improvements". If they would be implemented, different people would pick different subsets of these, effectively creating tons of dialects and fragmenting the language.

In a nutshell: -1

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extension Proposal: ArgumentBlock

Matthew Pickering
In reply to this post by Oliver Charles-3
>
> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extension Proposal: ArgumentBlock

Oliver Charles-3
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extension Proposal: ArgumentBlock

Tom Ellis
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extension Proposal: ArgumentBlock

Amos Robinson
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
1234