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

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.

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 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@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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On Sun, Sep 06, 2015 at 02:33:28PM -0430, Manuel Gómez wrote:

It seems to me that lately the community’s visible attitude has shifted toward a heightened value of stability and uniformity for Haskell and its software ecosystem, and experimentation, fragmentation and diversity in styles and dialects are now viewed as threatening. This drives us to reject the process of gradual improvement that has made Haskell great over the years. Other similarly purely syntactic extensions seem to me to have been met with less resistance in the past. It appears we’re now far more concerned with the pursuit of success.

+1

Hello Manuel, your post made me clearly realise why I am sometimes unhappy about syntactic extensions, so I'll take advantage of this discussion to illustrate my point. I don't recall the exact details, but a few months ago I was writing a small patch for a Haskell project I liked. Datatypes were simple, e.g.: data SomeData = SomeData { somedataName :: String , somedataVersion :: Int , somedataSynopsis :: Maybe String , somedataDescription :: Maybe String , somedataHomepage :: Maybe String , somedataBugReports :: Maybe String -- etc, etc. In the where part of the (long) top level function, I found an expression similar to this: -- there was no type sig there alfa = ("version", somedataVersion) A tuple with a String and an accessor `SomeData -> Int`, ok. Somewhere else this pops out: let beta = 7 + snd alfa What? For sure something is wrong, this program shouldn't compile! It should be: let beta = 7 + (snd alfa) myData I fired ghci, loaded the project and it turns out I was right and ghc wrong! λ> :t ("s", somedataVersion) ("s", somedataVersion) :: (String , SomeData -> Int) What was happening? A conspicuous bug in ghc (which was exploited in a weird way by the project developer)? Hallucinations? Not really! It turns out that in the top of the file, which looked like: {-# LANGUAGE CPP #-} {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE QuasiQuotes #-} {-# LANGUAGE RecordWildCards #-} {-# LANGUAGE ViewPatterns #-} I missed the `RecordWildCards` extension. RecordWildCards allows these kind of patterns: f (C {a = 1, ..}) = b + c + d -- shame on me for not checking extensions first! This long introduction to make my point :P

It seems to me that lately the community’s visible attitude has shifted toward a heightened value of stability and uniformity for Haskell and its software ecosystem, and experimentation, fragmentation and diversity in styles and dialects are now viewed as threatening. This drives us to reject the process of gradual improvement that has made Haskell great over the years.

Even though they aren't as 'dangerous' as other well known extensions, 5 small syntactic extensions potentially create 31 dialects which will make me trip in many different ways. One of the reason I like Haskell is because it's a joy to read other people's code (unlike other languages where I don't even try, so daunting is the challenge). I think it is healthy to have a thorough discussion for each one of the proposed extensions and most importantly study what we are trying to accomplish and see if there is a way to reach the same goal(s) with a smaller set of orthogonal changes. And yes, to err on the conservative side and say 'no' if the benefit isn't worth the additional fragmentation. I understand the fact that Haskell is meant to be an always evolving language: this is awesome and I like it. I like it even more when the community goes forward *together*! [1] Sorry for the long rant (phew, it took more words than necessary)! As written above, your message cleared my mind so I decided to share my thoughts, maybe they can be helpful to the discussion. [1] be it a Standard like H2010, a well thought out migration-path for changes like BPP, a stricter and curated selection for extensions, etc.

I'm coming from a less-informed background than most people, but isn't the fact that we need parentheses in the first place a bit odd? If Haskell's grammar went something like expression := (literal+) | doBlock, wouldn't the presence of the `do` keyword be enough for the parser to acknowledge the presence of a do block, and use the curly brackets inserted by the indent parser step to denote where the expression ends? In that case , it seems like that would solve the need for the $ issue, and make the parser simpler... Apologies if this is what's actually happening in this extension, but most people against this extension seem to say that it adds complexity. Could someone point out how things end up being more complex? My impression is that in the current state there's a difference in treatment between a do block and other expressions that is more complex than it should be. On Mon, Sep 7, 2015 at 8:44 AM Tikhon Jelvis wrote:

+1 from me. At a high level, one of the things that attracts me to Haskell over other languages is that it's willing to change and improve at a faster rate (although, in absolute terms, it's still pretty slow and concerned about backwards compatibility). Assuming a tweak makes sense, rolling it out as an extension and then folding it into the language (maybe as part of the mythical Haskell 2020 standard :)) is perfect. DoAndIfThenElse is a reasonable point of comparison and seems to be a good deal.

And I *do* think this tweak makes sense. The new behavior is more inline with my expectations. I feel that do and lambdas are self-contained expressions and inherently group their contents together; needing an extra set of parentheses or a $ does not make sense. A good way to think about it is that I see do as having braces semantically even when they're syntactically optional. I think most people would agree that requiring parentheses aroud

foo (do { x; y; z })

is redundant and not useful.

However, I would feel even better if this applied evenly to *all* syntactic elements that worked this way including case expressions. Were they left out just to make the proposal simpler? If you could change the grammar to support this for all the relevant syntactic constructions and it worked reasonably well, I would be significantly more enthusiastic about it. That would feel like a significant simplification of the syntax.

Also, it's worth noting that, as somebody pointed out in the Reddit thread, this extension would make the impredicativity magic around $ less necessary, which feels like a pointer that it *is* a simpler design.

On Sun, Sep 6, 2015 at 3:08 PM, Francesco Ariis wrote:

...

On Sun, Sep 06, 2015 at 02:33:28PM -0430, Manuel Gómez wrote:

...

It seems to me that lately the community’s visible attitude has shifted toward a heightened value of stability and uniformity for Haskell and its software ecosystem, and experimentation, fragmentation and diversity in styles and dialects are now viewed as threatening. This drives us to reject the process of gradual improvement that has made Haskell great over the years. Other similarly purely syntactic extensions seem to me to have been met with less resistance in the past. It appears we’re now far more concerned with the pursuit of success.

+1

Hello Manuel, your post made me clearly realise why I am sometimes unhappy about syntactic extensions, so I'll take advantage of this discussion to illustrate my point.

I don't recall the exact details, but a few months ago I was writing a small patch for a Haskell project I liked. Datatypes were simple, e.g.:

data SomeData = SomeData { somedataName :: String , somedataVersion :: Int , somedataSynopsis :: Maybe String , somedataDescription :: Maybe String , somedataHomepage :: Maybe String , somedataBugReports :: Maybe String -- etc, etc.

In the where part of the (long) top level function, I found an expression similar to this:

-- there was no type sig there alfa = ("version", somedataVersion)

A tuple with a String and an accessor `SomeData -> Int`, ok. Somewhere else this pops out:

let beta = 7 + snd alfa

What? For sure something is wrong, this program shouldn't compile! It should be:

let beta = 7 + (snd alfa) myData

I fired ghci, loaded the project and it turns out I was right and ghc wrong!

λ> :t ("s", somedataVersion) ("s", somedataVersion) :: (String , SomeData -> Int)

What was happening? A conspicuous bug in ghc (which was exploited in a weird way by the project developer)? Hallucinations? Not really! It turns out that in the top of the file, which looked like:

{-# LANGUAGE CPP #-} {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE QuasiQuotes #-} {-# LANGUAGE RecordWildCards #-} {-# LANGUAGE ViewPatterns #-}

I missed the `RecordWildCards` extension. RecordWildCards allows these kind of patterns:

f (C {a = 1, ..}) = b + c + d -- shame on me for not checking extensions first!

This long introduction to make my point :P

...

It seems to me that lately the community’s visible attitude has shifted toward a heightened value of stability and uniformity for Haskell and its software ecosystem, and experimentation, fragmentation and diversity in styles and dialects are now viewed as threatening. This drives us to reject the process of gradual improvement that has made Haskell great over the years.

Even though they aren't as 'dangerous' as other well known extensions, 5 small syntactic extensions potentially create 31 dialects which will make me trip in many different ways. One of the reason I like Haskell is because it's a joy to read other people's code (unlike other languages where I don't even try, so daunting is the challenge).

I think it is healthy to have a thorough discussion for each one of the proposed extensions and most importantly study what we are trying to accomplish and see if there is a way to reach the same goal(s) with a smaller set of orthogonal changes. And yes, to err on the conservative side and say 'no' if the benefit isn't worth the additional fragmentation.

I understand the fact that Haskell is meant to be an always evolving language: this is awesome and I like it. I like it even more when the community goes forward *together*! [1]

Sorry for the long rant (phew, it took more words than necessary)! As written above, your message cleared my mind so I decided to share my thoughts, maybe they can be helpful to the discussion.

[1] be it a Standard like H2010, a well thought out migration-path for changes like BPP, a stricter and curated selection for extensions, etc.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

2015-09-07 7:39 GMT+02:00 Bardur Arantsson :

(Please don't top-post... and please don't quote all of the previous message unless you really need to It breaks the flow of conversation.)

That's the bane of almost all new mail clients, having the totally wrong defaults, promoting threads of quadratic size, all in Yoda-style... :-P

Haskell keeps evolving at a brisk pace, see the depenently typed stuff that's coming up, etc.

Exactly, and let's not forget all the library-related changes (AMP, FTP/BBP, MonadFail, SemiGroup/Monoid, etc.): As much as the concrete syntax, the standard libraries constitute the basis of a common language. Given the already high velocity of changes in the libraries, let's no make things more complicated by introducing tons of ad hoc changes for no real value. Don't get me wrong, the library changes are really valuable and urgently needed, but they already put some non-trivial burden onto maintainers. Nevertheless, I'd like to see more cleanup/fixes in that area (e.g. an overhaul of Num and friends), but this would be item 0 in https://wiki.haskell.org/Wadler's_Law... ;-)

I question the value of constantly changing the *syntax*, which is mostly a triviality. The other syntactic extensions that we brought up saved a lot more than one character, btw!

IMHO it's not so much about saving characters, but more about generality and regularity: One can see e.g. LambdaCase as unification of, well, lambda and case, making them effectively just syntactic sugar. So by this reasoning, LambdaCase is a "good" extension. DoAndIfThenElse has a different quality: It just removes a very common pitfall, so personally I consider it "less good" than LambdaCase, but it still has some value. The proposed extension neither generalizes things nor does it remove a common pitfall => -1.

So, it looks like this extension is quite controversial. To summarize the main points raised in this discussion: Pro: (+9) - It's easier to read than the alternative. - This extension removes syntactic noise. - This makes basic do-syntax more approachable to newbies; it is a commonly asked question as to why the $ is necessary. - This simplifies the resulting AST, potentially making it simpler for editors and other tools to do refactoring. - It's something that belongs in the main language, and if its something we'd consider for a mythical Haskell', it has to start as an extension. - It gets rid of some cases where using $ doesn't work because $ interacts with other infix operators being used in the same expression. - This would make do blocks consistent with record creation, where parentheses are skipped, allowing things such as "return R { x = y}" - This does not change the meaning of any old programs, only allows new ones that were previously forbidden. - This gets rid of the need for a specially-typed $ allowing "runSt $ do ..." Con: (-9) - It's harder to read than the alternative. - Creating a language extension to get rid of a single character is overkill and unnecessary. - You can already get rid of the $ by just adding parentheses. - More and more syntactic "improvements" just fragment the language. - Although this is consistent with record syntax, record syntax without parents was a mistake originally. Questions: - Why doesn't this apply to case, let, if, etc? - Should this apply to case, let, if, etc? I would say people on /r/haskell and haskell-cafe seem fairly evenly split, perhaps somewhat favoring *not* including this extension. 1. How representative are the opinions expressed through these media of the general Haskell community? (If one exists...) 2. What, historically, has been the GHC policy on including questionable/controversial extensions? 3. We do have another option: with the advent of ghc-exactprint, we could probably write a preprocessor that emulates this extension, parsing as if ArgumentDo is enabled and then inserting a $ where necessary. This would allow us to test out this extension without modifying GHC and thus being stuck with the extension in mainline GHC indefinitely (since, as I understand it, there's not really a process for *removing* extensions from GHC). On Mon, Sep 7, 2015 at 5:10 AM, Joachim Breitner wrote:

Hi,

Am Sonntag, den 06.09.2015, 11:28 -0700 schrieb Andrew Gibiansky:

...

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.)

good point! This has bitten me before.

I believe that the language would be better with the proposed syntax change being the default. So the way forward is to indeed add this extension, see how people use it, and if Haskell' ever goes somewhere, it might include this as the default – all alike to DoAndIfThenElse.

Also note that this does not change the meaning of any existing program, AFAIK. So it is not that you might be reading existing code wrongly if you are not aware that this extension is being used; you will just find code that looks like invalid syntax to you – until you check the list of extensions (or just deduce that ArgumentBlock is used here).

Therefore, +1 from me.

Greetings, Joachim

-- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

We would need ghc-exactprint to provide a good source to source transformation for error messages. Otherwise using this quasi-extension would be quite problematic in real-world work. I actually really like this idea -- it would give us a way to experiment with new syntax easily, including things such as changing `type`, `data`, `newtype`, and any other syntactic woes we might have about the Haskell language. -- Andrew On Mon, Sep 7, 2015 at 11:25 AM, Oliver Charles wrote:

I don't think you need ghc-exactprint for that - you can just write a GHC preprocessor, hopefully being able to reuse the current grammar specification you already have. See the -prgmF option (I think it's called that, best check the GHC manual). You don't really care about the source code formatting, because you're going to pass it straight off to the compiler anyway. Though I guess maybe exactprint could help so error messages still map cleanly.

On Mon, Sep 7, 2015 at 6:57 PM Andrew Gibiansky < andrew.gibiansky@gmail.com> wrote:

...

So, it looks like this extension is quite controversial. To summarize the main points raised in this discussion:

Pro: (+9) - It's easier to read than the alternative. - This extension removes syntactic noise. - This makes basic do-syntax more approachable to newbies; it is a commonly asked question as to why the $ is necessary. - This simplifies the resulting AST, potentially making it simpler for editors and other tools to do refactoring. - It's something that belongs in the main language, and if its something we'd consider for a mythical Haskell', it has to start as an extension. - It gets rid of some cases where using $ doesn't work because $ interacts with other infix operators being used in the same expression. - This would make do blocks consistent with record creation, where parentheses are skipped, allowing things such as "return R { x = y}" - This does not change the meaning of any old programs, only allows new ones that were previously forbidden. - This gets rid of the need for a specially-typed $ allowing "runSt $ do ..."

Con: (-9) - It's harder to read than the alternative. - Creating a language extension to get rid of a single character is overkill and unnecessary. - You can already get rid of the $ by just adding parentheses. - More and more syntactic "improvements" just fragment the language. - Although this is consistent with record syntax, record syntax without parents was a mistake originally.

Questions: - Why doesn't this apply to case, let, if, etc? - Should this apply to case, let, if, etc?

I would say people on /r/haskell and haskell-cafe seem fairly evenly split, perhaps somewhat favoring *not* including this extension.

1. How representative are the opinions expressed through these media of the general Haskell community? (If one exists...) 2. What, historically, has been the GHC policy on including questionable/controversial extensions? 3. We do have another option: with the advent of ghc-exactprint, we could probably write a preprocessor that emulates this extension, parsing as if ArgumentDo is enabled and then inserting a $ where necessary. This would allow us to test out this extension without modifying GHC and thus being stuck with the extension in mainline GHC indefinitely (since, as I understand it, there's not really a process for *removing* extensions from GHC).

On Mon, Sep 7, 2015 at 5:10 AM, Joachim Breitner < mail@joachim-breitner.de> wrote:

...

Hi,

Am Sonntag, den 06.09.2015, 11:28 -0700 schrieb Andrew Gibiansky:

...

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.)

good point! This has bitten me before.

I believe that the language would be better with the proposed syntax change being the default. So the way forward is to indeed add this extension, see how people use it, and if Haskell' ever goes somewhere, it might include this as the default – all alike to DoAndIfThenElse.

Also note that this does not change the meaning of any existing program, AFAIK. So it is not that you might be reading existing code wrongly if you are not aware that this extension is being used; you will just find code that looks like invalid syntax to you – until you check the list of extensions (or just deduce that ArgumentBlock is used here).

Therefore, +1 from me.

Greetings, Joachim

-- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On Mon, Sep 7, 2015 at 8:08 PM Dan Burton wrote:

+1 people who like it can use it and people who don't like it don't have to use it.

Yes, but they still have to be able to read code that uses it, deal with it in coding standards, deal with how it affects their tool chain, and otherwise have it affect them. "If you don't like it, don't use it" is a bogus argument, and should be shot on sight.

Very little changes. You can look at the changes to Parser.y on the Phabricator revision https://phabricator.haskell.org/D1219#72873ca7. In order to get this parsing sans any shift/reduce conflicts you have to introduce fexp2 as well as fexp, which makes it so that dollar-less lambdas/do blocks can only be applied as the last argument. -- Andrew On Mon, Sep 7, 2015 at 6:39 PM, Edward Kmett wrote:

Reserving judgment on the merits of the proposal, I would be curious to see the net impact of such a change on the grammar that GHC parses. How much changes?

-Edward

On Mon, Sep 7, 2015 at 9:15 PM, Mike Meyer wrote:

...

On Mon, Sep 7, 2015 at 8:08 PM Dan Burton wrote:

...

+1 people who like it can use it and people who don't like it don't have to use it.

Yes, but they still have to be able to read code that uses it, deal with it in coding standards, deal with how it affects their tool chain, and otherwise have it affect them.

"If you don't like it, don't use it" is a bogus argument, and should be shot on sight.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

In order to get a feel for using this extension in real-world Haskell, take a look at the new ghc-reskin package: https://github.com/gibiansky/ghc-reskin This allows you to use ArgumentBlock *today* by passing GHC a few parameters to tell it to use ghc-reskin as a preprocessor. Take a look at the README for a full example. -- Andrew On Mon, Sep 7, 2015 at 9:02 PM, Bardur Arantsson wrote:

On 09/08/2015 03:08 AM, Dan Burton wrote:

...

+1 people who like it can use it and people who don't like it don't have to use it. Personally I wish it were the default because the superfluous $ confuses a lot of people coming from other languages like Ruby.

Whether it's "superfluous" depends entirely on one's PoV.

...

You can even write in the old style if you have the extension turned on. It doesn't disable the old way of doing things. It just allows a new way. It's entirely backwards compatible with working code when turned on, is it not?

Except now there are two "dialects" everybody has to read/understand. That's not progress IMO. (Considering that it's so little gain. I really don't understand the hatred of $ that some people seem to have.)

Regards,

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

FWIW, I’m neutral. Simon From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Edward Kmett Sent: 08 September 2015 08:05 To: Andrew Gibiansky Cc: Haskell Cafe Subject: Re: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock I do have to admit that the syntax there feels lighter and less cluttered. I could get used to it. -Edward On Tue, Sep 8, 2015 at 12:56 AM, Andrew Gibiansky mailto:andrew.gibiansky@gmail.com> wrote: In order to get a feel for using this extension in real-world Haskell, take a look at the new ghc-reskin package: https://github.com/gibiansky/ghc-reskin This allows you to use ArgumentBlock *today* by passing GHC a few parameters to tell it to use ghc-reskin as a preprocessor. Take a look at the README for a full example. -- Andrew On Mon, Sep 7, 2015 at 9:02 PM, Bardur Arantsson mailto:spam@scientician.net> wrote: On 09/08/2015 03:08 AM, Dan Burton wrote:

+1 people who like it can use it and people who don't like it don't have to use it. Personally I wish it were the default because the superfluous $ confuses a lot of people coming from other languages like Ruby.

Whether it's "superfluous" depends entirely on one's PoV.

You can even write in the old style if you have the extension turned on. It doesn't disable the old way of doing things. It just allows a new way. It's entirely backwards compatible with working code when turned on, is it not?

Except now there are two "dialects" everybody has to read/understand. That's not progress IMO. (Considering that it's so little gain. I really don't understand the hatred of $ that some people seem to have.) Regards, _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.orgmailto:Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.orgmailto:Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

+1 for the change but not for an extension. Here's why 1. I remember when I was new to Haskell, having to add $ confused me a lot. It caused a lot of frustration, some errors I didn't understand, which didn't help me realize that $ was needed. I still vividly remember the pain.... 2. It seems the change is fully backwards compatible and it does not prevent people still using the old style if they wanted. I would make it a default, not an extension. 3. In order to verify backwards compatibility, I would generate Core output for all of Hackage with both the current and the new compilers and check that Core remains identical. That would be a conclusive proof to me. 4. Regarding the other mentioned extensions like multiway if, etc. they should become default as well because they are backwards compatible as well. 5. The only reason to guard changes behind LANGUAGE pragmas should be when they are causing problems with other extensions. I too feel that Haskell community is becoming more and more conservative. I believe there's still time now to make the language as best it can be at the cost of loosing backwards compatibility. The rapid improvements in the language is what attracts me to Haskell. Best, Michał On Tue, Sep 8, 2015 at 12:56 AM, Andrew Gibiansky < andrew.gibiansky@gmail.com> wrote:

In order to get a feel for using this extension in real-world Haskell, take a look at the new ghc-reskin package:

https://github.com/gibiansky/ghc-reskin

This allows you to use ArgumentBlock *today* by passing GHC a few parameters to tell it to use ghc-reskin as a preprocessor. Take a look at the README for a full example.

-- Andrew

On Mon, Sep 7, 2015 at 9:02 PM, Bardur Arantsson wrote:

...

On 09/08/2015 03:08 AM, Dan Burton wrote:

...

+1 people who like it can use it and people who don't like it don't have to use it. Personally I wish it were the default because the superfluous $ confuses a lot of people coming from other languages like Ruby.

Whether it's "superfluous" depends entirely on one's PoV.

...

You can even write in the old style if you have the extension turned on. It doesn't disable the old way of doing things. It just allows a new way. It's entirely backwards compatible with working code when turned on, is it not?

Except now there are two "dialects" everybody has to read/understand. That's not progress IMO. (Considering that it's so little gain. I really don't understand the hatred of $ that some people seem to have.)

Regards,

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Anything that is not Haskell 2010 is *by definition* a language extension. If you want to change the language, that is a discussion for Haskell' not GHC.

I'm not sure this is entirely true. In ghc file compiler/parser/Lexer.x it is stated. -- Pushing a new implicit layout context. If the indentation of the -- next token is not greater than the previous layout context, then -- Haskell 98 says that the new layout context should be empty; that is -- the lexer must generate {}. -- -- We are slightly more lenient than this: when the new context is start ed -- by a 'do', then we allow the new context to be at the same indentation as -- the previous context. This is what the 'strict' argument is for. I think this means that the following is valid in ghc but not in haskell 98/2010. main :: IO () main = do if True then return () else do return () Silvio

That's still an extension (-XNondecreasingIndentation), just one enabled by default.

Interesting. Is there a list of extensions that are enabled by default? I'm sure whoever suggested it as default and not extension will be happy with this too. BTW, +1 from me for the proposal. Silvio

You mean this? languageExtensions Nothing -- Nothing => the default case = Opt_NondecreasingIndentation -- This has been on by default for some time : delete Opt_DatatypeContexts -- The Haskell' committee decided to -- remove datatype contexts from the -- language: -- http://www.haskell.org/pipermail/haskell-prime/2011-January/003335.html (languageExtensions (Just Haskell2010)) So default is haskell2010+NondecreasingIndentation-DatatypeContexts But the standard library can not be made to adhere to haskell98/2010. I.e. Monad is now a subclass of Applicative. Silvio

"The spec"... Maybe we need a more lightweight process: Every two years, a committee gathers and issues a statement: "Haskell 2016 includes the following extensions by default: <list>". And remove the corresponding language pragmas. And we call that the new spec, that's it. There's no point in holding off everybody down to Haskell 2010. Haskell' is dead, nobody works on the full-blown spec, etc. There's a wide consensus in the community about certain extensions. Let's just make them default for the benefit of all (or at least the vast majority). Michał On Tue, Sep 8, 2015 at 10:35 AM, Niklas Larsson wrote:

I would be unhappy if GHC included gratuitous differences from the Haskell spec by default. It's hard enough for people working on alternative Haskell implementations as is, stepping away from the spec would be a movie in the wrong direction. ------------------------------ Från: Michal Antkiewicz Skickat: ‎2015-‎09-‎08 16:10 Till: Haskell Cafe Ämne: Re: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock

+1 for the change but not for an extension. Here's why

1. I remember when I was new to Haskell, having to add $ confused me a lot. It caused a lot of frustration, some errors I didn't understand, which didn't help me realize that $ was needed. I still vividly remember the pain....

2. It seems the change is fully backwards compatible and it does not prevent people still using the old style if they wanted. I would make it a default, not an extension.

3. In order to verify backwards compatibility, I would generate Core output for all of Hackage with both the current and the new compilers and check that Core remains identical. That would be a conclusive proof to me.

4. Regarding the other mentioned extensions like multiway if, etc. they should become default as well because they are backwards compatible as well.

5. The only reason to guard changes behind LANGUAGE pragmas should be when they are causing problems with other extensions.

I too feel that Haskell community is becoming more and more conservative. I believe there's still time now to make the language as best it can be at the cost of loosing backwards compatibility. The rapid improvements in the language is what attracts me to Haskell.

Best, Michał

On Tue, Sep 8, 2015 at 12:56 AM, Andrew Gibiansky < andrew.gibiansky@gmail.com> wrote:

...

In order to get a feel for using this extension in real-world Haskell, take a look at the new ghc-reskin package:

https://github.com/gibiansky/ghc-reskin

This allows you to use ArgumentBlock *today* by passing GHC a few parameters to tell it to use ghc-reskin as a preprocessor. Take a look at the README for a full example.

-- Andrew

On Mon, Sep 7, 2015 at 9:02 PM, Bardur Arantsson wrote:

...

On 09/08/2015 03:08 AM, Dan Burton wrote:

...

+1 people who like it can use it and people who don't like it don't have to use it. Personally I wish it were the default because the superfluous $ confuses a lot of people coming from other languages like Ruby.

Whether it's "superfluous" depends entirely on one's PoV.

...

You can even write in the old style if you have the extension turned on. It doesn't disable the old way of doing things. It just allows a new way. It's entirely backwards compatible with working code when turned on, is it not?

Except now there are two "dialects" everybody has to read/understand. That's not progress IMO. (Considering that it's so little gain. I really don't understand the hatred of $ that some people seem to have.)

Regards,

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On Tue, Sep 8, 2015 at 10:55 AM, Michal Antkiewicz < mantkiew@gsd.uwaterloo.ca> wrote:

"The spec"... Maybe we need a more lightweight process:

Every two years, a committee gathers and issues a statement:

"Haskell 2016 includes the following extensions by default: <list>". And remove the corresponding language pragmas.

I have no objection to adding such extensions we find warranted to Haskell201X, merely to their willy nilly addition to the language without a pragma outside of any such a process. Even for the bits included in Haskell2010 we didn't remove the corresponding LANGUAGE pragmas from existence, merely specified that when you are using {-# LANGUAGE Haskell2010 #-} or tell cabal to use default-language: Haskell2010 then they turn on by default.

There's no point in holding off everybody down to Haskell 2010. Haskell' is dead, nobody works on the full-blown spec, etc.

Herbert is in the middle of rebooting the Haskell' process, I wouldn't count it out yet. -Edward

There's a wide consensus in the community about certain extensions. Let's just make them default for the benefit of all (or at least the vast majority).

Michał

On Tue, Sep 8, 2015 at 10:35 AM, Niklas Larsson wrote:

...

I would be unhappy if GHC included gratuitous differences from the Haskell spec by default. It's hard enough for people working on alternative Haskell implementations as is, stepping away from the spec would be a movie in the wrong direction. ------------------------------ Från: Michal Antkiewicz Skickat: ‎2015-‎09-‎08 16:10 Till: Haskell Cafe Ämne: Re: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock

+1 for the change but not for an extension. Here's why

1. I remember when I was new to Haskell, having to add $ confused me a lot. It caused a lot of frustration, some errors I didn't understand, which didn't help me realize that $ was needed. I still vividly remember the pain....

2. It seems the change is fully backwards compatible and it does not prevent people still using the old style if they wanted. I would make it a default, not an extension.

3. In order to verify backwards compatibility, I would generate Core output for all of Hackage with both the current and the new compilers and check that Core remains identical. That would be a conclusive proof to me.

4. Regarding the other mentioned extensions like multiway if, etc. they should become default as well because they are backwards compatible as well.

5. The only reason to guard changes behind LANGUAGE pragmas should be when they are causing problems with other extensions.

I too feel that Haskell community is becoming more and more conservative. I believe there's still time now to make the language as best it can be at the cost of loosing backwards compatibility. The rapid improvements in the language is what attracts me to Haskell.

Best, Michał

On Tue, Sep 8, 2015 at 12:56 AM, Andrew Gibiansky < andrew.gibiansky@gmail.com> wrote:

...

In order to get a feel for using this extension in real-world Haskell, take a look at the new ghc-reskin package:

https://github.com/gibiansky/ghc-reskin

This allows you to use ArgumentBlock *today* by passing GHC a few parameters to tell it to use ghc-reskin as a preprocessor. Take a look at the README for a full example.

-- Andrew

On Mon, Sep 7, 2015 at 9:02 PM, Bardur Arantsson wrote:

...

On 09/08/2015 03:08 AM, Dan Burton wrote:

...

+1 people who like it can use it and people who don't like it don't have to use it. Personally I wish it were the default because the superfluous $ confuses a lot of people coming from other languages like Ruby.

Whether it's "superfluous" depends entirely on one's PoV.

...

You can even write in the old style if you have the extension turned on. It doesn't disable the old way of doing things. It just allows a new way. It's entirely backwards compatible with working code when turned on, is it not?

Except now there are two "dialects" everybody has to read/understand. That's not progress IMO. (Considering that it's so little gain. I really don't understand the hatred of $ that some people seem to have.)

Regards,

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On Tue, Sep 8, 2015 at 11:18 AM, Michal Antkiewicz < mantkiew@gsd.uwaterloo.ca> wrote:

Ah, sure, yes, they should be kept. I don't care about removing them. However, perhaps after some long time (10 years, 15..?) maybe some garbage collection of unused pragmas could be done. The same way we remove old CPP IFDEFs when we no longer need to support the old compiler or library version. This just reduces the complexity of the code.

Doing so would basically rule out compiling versions of the language that predates the cleanup. Given that I don't see GHC dropping support for Haskell98 any time soon, this seems more or less an academic concern, or one for far flung future generations of Haskellers. =) -Edward

On Tue, Sep 8, 2015 at 12:48 PM, Manuel Gómez wrote:

You must be quite unhappy. From the GHC user manual:

Most of that list is *not* enabled by default, which was the specific assertion. AFAIK the only one that is is NondecreasingIndentation, and that one is more or less grandfathered because it's too late to change. (I also suspect it is top of the list for a next version of the Haskell standard.) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On 09/08/2015 12:48 PM, Manuel Gómez wrote:

§7.3.3. Negative literals: The literal `-123` is, according to Haskell98 and Haskell 2010, desugared as `negate (fromInteger 123)`. The language extension `-XNegativeLiterals` means that it is instead desugared as `fromInteger (-123)`.

Totally off-topic, but this is cute =)

On Tue, Sep 8, 2015 at 10:10 AM, Michal Antkiewicz < mantkiew@gsd.uwaterloo.ca> wrote:

+1 for the change but not for an extension. Here's why

5. The only reason to guard changes behind LANGUAGE pragmas should be when they are causing problems with other extensions.

There is a massive downside to this view. It only permits monotonic progress in one direction. If we later learn about a better thing we could have done, you can never really retract it. There are a lot of historically proposed extensions that 'don't break anything' that you've never heard of that subtly conflict with other extensions that 'don't break anything'. Trex-records, half a dozen layout rule variants, I don't know how to resolve both naked existential types in UHC and type families in GHC... Each of these chip away at some innocuous corner of our syntax or semantics, but in aggregate they'd leave us no room to grow, and no ability to know if we'd written portable, standards compliant, code. The LANGUAGE pragma is an annoying tax, but I think the long term benefits in terms of readability of new extensions makes it worth it. Look at languages like C++ and what horrible things they have to call everything to avoid conflicting with every random historical idea baked into the standard. Let's not go down that road. You can always amortize the cost of those LANGUAGE pragmas by embedding them in the extensions field of your cabal file if you feel they must be on at all times in the code you write -- and since the ones you are interested in are 'just extensions that don't break anything' this causes you no pain when reading other people's code as they just don't use your favorite extension. -Edward Best,

Michał

On Tue, Sep 8, 2015 at 12:56 AM, Andrew Gibiansky < andrew.gibiansky@gmail.com> wrote:

...

In order to get a feel for using this extension in real-world Haskell, take a look at the new ghc-reskin package:

https://github.com/gibiansky/ghc-reskin

This allows you to use ArgumentBlock *today* by passing GHC a few parameters to tell it to use ghc-reskin as a preprocessor. Take a look at the README for a full example.

-- Andrew

On Mon, Sep 7, 2015 at 9:02 PM, Bardur Arantsson wrote:

...

On 09/08/2015 03:08 AM, Dan Burton wrote:

...

+1 people who like it can use it and people who don't like it don't have to use it. Personally I wish it were the default because the superfluous $ confuses a lot of people coming from other languages like Ruby.

Whether it's "superfluous" depends entirely on one's PoV.

...

You can even write in the old style if you have the extension turned on. It doesn't disable the old way of doing things. It just allows a new way. It's entirely backwards compatible with working code when turned on, is it not?

Except now there are two "dialects" everybody has to read/understand. That's not progress IMO. (Considering that it's so little gain. I really don't understand the hatred of $ that some people seem to have.)

Regards,

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On 09/08/2015 06:57 AM, Manuel Gómez wrote:

On 09/08/2015 03:08 AM, Dan Burton wrote:

...

You can even write in the old style if you have the extension turned on. It doesn't disable the old way of doing things. It just allows a new way. It's entirely backwards compatible with working code when turned on, is it not?

On Mon, Sep 7, 2015 at 11:32 PM, Bardur Arantsson wrote:

...

Except now there are two "dialects" everybody has to read/understand. That's not progress IMO. (Considering that it's so little gain. I really don't understand the hatred of $ that some people seem to have.)

Every library published on Hackage could be said to create a new dialect of Haskell for some specific purpose. Operator-heavy, multipurpose libraries such as lens could also be said to introduce new dialects. Yes, they all parse under the same grammar, but if you don’t know the fixity of some operator, it might as well be some strange unknown syntax — let alone not knowing what it actually does.

We’re so used to understanding complex semantics and diverse, sometimes even obtuse styles of expression (pointfree, anyone?). Surely the mental effort of parsing a lambda or a do-block in a new, previously invalid syntax is a trivial matter for programmers accustomed to running type checking algorithms in our heads.

If this were LISP or Scheme (i.e. macros), I'd agree with you :). Needless to say, I don't when it comes to Haskell. (Again because this adds *so* little convenience.) Regards,

2015-09-06 20:17 GMT+02:00 Amos Robinson :

If you made tooling aware of ($) would you need to check that it is importing the Prelude version and not another one?

Every non-toy refactoring tool (and I guess a lot of other ones) needs to understand fixity declarations, imports, scopes etc. anyway, otherwise it would be next to useless.

Not that I'm suggesting that having a different implementation would be sensible.

"Sensible" is always a subjective notion, and tools should not have subjective behavior. :-) In other words: If it's legal, the tool must handle it. A lot of things which were initially considered nonsense/impractical/confusing are mainstream nowadays. Furthermore, there are a few experimental Prelude variants out there.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ($) is just a function like any other*, so I don't think it's a great argument for or against a syntax extension. *Bar a few details like the special infix typing rule for accommodating impredicative polymorphism. - -- Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJV7uQDAAoJENQqWdRUGk8BA3wQAMdZ3xHQDYUy17HahMbMjxyT xkm2bZLDNMPwmyaciGHsC+BeRae9Oo1oVgjWDDzrL41zSf9e2GS5SmEQumJeAgLm TNkJgctJ44Ej+yPnJkik9OCK4YsFjZPFYdj8iI4T7uEBfC5vDQczODgKvcXo3WiY JmujgC+QFjU3PaDaz8HZ8UzDIRszBRPQyTTLzlYnsshQwws/eU7W1hBKBLNFjn90 t9n8xq49BfbNInHSzVy5CbUW5VyPCYikkCAz7zRBc25iWtaXODvYnDCyc4vwVg38 QsNfXvOsSrnE80WOQxXKbaHutMaf8QoiNQ5+M8gMNKWAHXZ0ROYgAE9lm2QfLMTE oidjVh9WrYmlXCmJl0pgFdN1Dc5J+KimoTK8ttvGcweRckUdgkBRQsmyqILtn+ql peNN9QU5W1V8rUfliTq9XCXDu1rAKuKtSPb3GQD9vXDQ22QSHQqjk8eLdd2bAK1n ji/r+Bjp9XNLvySaPi9neiEp3geFjZnN7b3pC2QtDsRJozv6prliNHOsGgLin5dN FmrwSXysha7hZtxy3ze4XnMa/91GZPB9Z91hZdALXyVSbDBrE4ukUABprI6tK8/6 O2pfmsdWzvGMNgXFibg1sgJk9e8aTvp6YPyi6Xyj/88hLD6YxB3/ekxxBy00EDW/ RFqKfswkYKypfKwx0FXq =8Rg1 -----END PGP SIGNATURE-----

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

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? Cheers, Oliver Batchelor On Wed, Sep 9, 2015 at 12:36 AM, 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 :

...

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> 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-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 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 Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

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

On Sun, Sep 6, 2015 at 1:46 PM Tom Ellis < tom-lists-haskell-cafe-2013@jaguarpaw.co.uk> 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 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 < tom-lists-haskell-cafe-2013@jaguarpaw.co.uk> 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.

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 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 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 Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

---

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-1 This is additional arbitrariness in the syntax for little gain and will not make anything more approachable for new people. On Sun, Sep 6, 2015 at 1:57 AM, Bardur Arantsson 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 Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Chris Allen Currently working on http://haskellbook.com