Re: Proposal: ArgumentDo

Hi Sven, a wrongly spelled keyword will soon be detected by the checker in either cases. Readability is the responsibility of programmers. It is up to you or a team to use parentheses for the examples below. (I find a line break and indentation to be sufficient.) (I know people - mostly

Re: Proposal: ArgumentDo

Hi, Am Montag, den 11.07.2016, 08:31 +0200 schrieb Sven Panne: > Because at first glance, this is visually only a tiny fraction away > from >   >    (if c then f else g)  it d them a elsa b > > which would be parsed in a totally different way. (Personally, I > think that if/then/else is useless

Re: Proposal: ArgumentDo

2016-07-10 11:28 GMT+02:00 C Maeder : > [...] Why does an explicit infix operator make such a big difference for > you? > > (if c then f else g) $ if d then a else b > > (if c then f else g) if d then a else b > [...] > Because at first glance, this is visually only a

Re: Proposal: ArgumentDo

Akio, Yes, definitely! I think I was a bit unclear, but what I was trying to say was that, in the (rare) circumstances in which I'm editing Haskell without the benefit of syntax highlighting, the difference between keywords and identifiers is not quite as obvious. In those cases, requiring an

Re: Proposal: ArgumentDo

Hi Henrik, On 9 July 2016 at 09:46, Henrik Nilsson wrote: > Hi all, > > On 07/09/2016 08:09 AM, C Maeder wrote: >> >> The asymmetry that you mention is already apparent for (Haskell98) infix >> expressions, i.e. when "composing" lambda- or if-expression: >> >>

Re: Proposal: ArgumentDo

Hi Ryan, On 7 July 2016 at 19:40, Ryan Trinkle wrote: > I'm very on the fence on this topic, but one point i haven't seen mentioned > is the influence of syntax highlighting on this. My guess is that I would > like this extension when I have syntax highlighting available

Re: Proposal: ArgumentDo

Hi Christian, On 6 July 2016 at 16:08, C Maeder wrote: > Hi, > > allowing group A constructs (do, case, ...) and group B constructs (\, > let, if, ...) as parts of functions application (fexp) without extra > parentheses looks natural to me. The current state is an artificial

Re: Proposal: ArgumentDo

Hi Henrik apologize my "d" in your name below. Am 10.07.2016 um 11:28 schrieb C Maeder: > Hi Hendrik, > > juxtaposition (of grammar non-terminals aexp) is function application in > Haskell. > > Why does an explicit infix operator make such a big difference for you? > > (if c then f else g)

Re: Proposal: ArgumentDo

Hi Hendrik, juxtaposition (of grammar non-terminals aexp) is function application in Haskell. Why does an explicit infix operator make such a big difference for you? (if c then f else g) $ if d then a else b (if c then f else g) if d then a else b The keyword "if" starts a new

Re: Proposal: ArgumentDo

On Saturday, July 9, 2016, Henrik Nilsson wrote: > Hi all, > > On 07/09/2016 08:09 AM, C Maeder wrote: > >> The asymmetry that you mention is already apparent for (Haskell98) infix >> expressions, i.e. when "composing" lambda- or if-expression: >> >> (if c then

Re: Proposal: ArgumentDo

Hi all, On 07/09/2016 08:09 AM, C Maeder wrote: The asymmetry that you mention is already apparent for (Haskell98) infix expressions, i.e. when "composing" lambda- or if-expression: (if c then f else g) . \ x -> h x Parentheses around the last argument of "." do not matter, but parentheses

Re: Proposal: ArgumentDo

On 07/09/2016 09:09 AM, C Maeder wrote: > The asymmetry that you mention is already apparent for (Haskell98) infix > expressions, i.e. when "composing" lambda- or if-expression: > > (if c then f else g) . \ x -> h x > > Parentheses around the last argument of "." do not matter, but >

Re: Proposal: ArgumentDo

The asymmetry that you mention is already apparent for (Haskell98) infix expressions, i.e. when "composing" lambda- or if-expression: (if c then f else g) . \ x -> h x Parentheses around the last argument of "." do not matter, but parentheses around the first argument make a real difference

Re: Proposal: ArgumentDo

Hello, while we are voting here, I kind of like this proposal, so +1 for me. I understand that some of the examples look strange to Haskell old-timers but, as Joachim points out, the behavior is very consistent. Besides, the "Less Obvious Examples" were selected so that they are, well, less

layout was Re: Proposal: ArgumentDo

Hi, the layout language options are hard to find (at least in the user guide). Therefore I try to give an overview here. The relevant options I've found by using ghc-7.10.3 with option --supported-languages are: NondecreasingIndentation DoAndIfThenElse RelaxedLayout AlternativeLayoutRule

Re: Proposal: ArgumentDo

-1 for same reasons. On 8 July 2016 at 14:00, Henrik Nilsson wrote: > Hi all, > > Joachim Breitner wrote: > > > Am Freitag, den 08.07.2016, 13:09 +0200 schrieb Sven Panne: > > > I don't think so: https://ghc.haskell.org/trac/ghc > > /wiki/ArgumentDo#Bl > > [...]

Re: Proposal: ArgumentDo

Hi all, Joachim Breitner wrote: > Am Freitag, den 08.07.2016, 13:09 +0200 schrieb Sven Panne: > > I don't think so: https://ghc.haskell.org/trac/ghc > /wiki/ArgumentDo#Bl > [...] > Where is the outer set of parenthesis coming from? > > This is all not related to the ArgumentDo notation. Note

Re: Proposal: ArgumentDo

Hi, Am Freitag, den 08.07.2016, 13:09 +0200 schrieb Sven Panne: > I don't think so: https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo#Bl > ockasaLHS explicit states that > >    do f &&& g >    x > > parses as > >    (f &&& g) x Correct > , so > >    foobar >       do f &&& g >       x > >

Re: Proposal: ArgumentDo

2016-07-08 12:28 GMT+02:00 Joachim Breitner : > Currenlty, > > foobar > (do f &&& g) > x > > calls foobar with two arguments, while > > (do f &&& g) > x > > calls (f &&& g) with one argument. The ArgumentDo proposal does not change > that, only

Re: Proposal: ArgumentDo

Hi, Am Freitag, den 08.07.2016, 11:32 +0200 schrieb Sven Panne: > 2016-07-08 9:09 GMT+02:00 Joachim Breitner : > > Am Freitag, den 08.07.2016, 08:35 +0200 schrieb Sven Panne: > > >    foobar > > >       do f &&& g > > >       x > > [...] Only with the proposed addition,

Re: Proposal: ArgumentDo

2016-07-08 9:09 GMT+02:00 Joachim Breitner : > Am Freitag, den 08.07.2016, 08:35 +0200 schrieb Sven Panne: > >foobar > > do f &&& g > > x > [...] Only with the proposed addition, it becomes an argument to foobar. > [...] > Huh? Nope! The Wiki page

Re: Proposal: ArgumentDo

Surely layout can bite you: f do x do y and I'm having difficulties to find the documentation for the various layout options. But this is no argument against this proposal! Improper use of white spaces can always be used to obfuscate code! Style guides are important. Furthermore, a

Re: Proposal: ArgumentDo

Hi, Am Freitag, den 08.07.2016, 08:35 +0200 schrieb Sven Panne: >    foobar >       do f &&& g >       x > > Should the x now be an argument of foobar (as it is currently) or the > "do"? If it is not an argument of the "do", suddenly things get very > context-dependent. Computers are good at

Re: Proposal: ArgumentDo

[ There is a trend to repeat one's argument about this proposed extension in various mailing lists/wiki pages/etc., so let's repeat myself, too... :-] 2016-07-07 19:44 GMT+02:00 Carter Schonwald : > the fact that its perilously close to looking like *1 typo* away from

Re: Proposal: ArgumentDo

Can you walk me through how this simplifies the grammar etc in concrete compare contrast or what the diffs between the grammar and associated engineering would be? I don't see how it simplifies the grammar, but I could be a bit obtuse. That aside, I'm also a bit fuzzy on the other claim, that

Re: Proposal: ArgumentDo

> ambiguity is bad for humans, not just parsers. This is not ambiguous. It’s removing the need for a redundant set of parentheses, whichever way you slice it. Of course, some redundancy is useful for readability (look at natural language), but you should really be explicit if you’re arguing from

Re: Proposal: ArgumentDo

I'm very on the fence on this topic, but one point i haven't seen mentioned is the influence of syntax highlighting on this. My guess is that I would like this extension when I have syntax highlighting available and would dislike it when I do not. Also, I agree with Carter about the record

Re: Proposal: ArgumentDo

Hi, Am Donnerstag, den 07.07.2016, 13:15 -0400 schrieb Carter Schonwald: > agreed -1, > ambiguity is bad for humans, not just parsers.  > > perhaps most damningly,  > > f do{ x } do { y } > > is just reallly really weird/confusing to me, It is weird to me, but in no way confusing under the

Re: Proposal: ArgumentDo

the fact that its perilously close to looking like *1 typo* away from a parser error about record syntax makes me *-1000* now thanks for pointing this out! On Thu, Jul 7, 2016 at 1:32 PM, Brandon Allbery wrote: > Didn't they already say they disliked record syntax for

Re: Proposal: ArgumentDo

Didn't they already say they disliked record syntax for exactly that reason? On Thu, Jul 7, 2016 at 1:23 PM, David Feuer wrote: > What makes > > f do{x} do{y} > > any harder to read than similar record syntax? > > f Foo{foo=3} Foo{foo=4} > > On Thu, Jul 7, 2016 at 1:15

Re: Proposal: ArgumentDo

What makes f do{x} do{y} any harder to read than similar record syntax? f Foo{foo=3} Foo{foo=4} On Thu, Jul 7, 2016 at 1:15 PM, Carter Schonwald wrote: > agreed -1, > ambiguity is bad for humans, not just parsers. > > perhaps most damningly, >> >> >> f do{ x } do {

Re: Proposal: ArgumentDo

agreed -1, ambiguity is bad for humans, not just parsers. perhaps most damningly, > f do{ x } do { y } is just reallly really weird/confusing to me, and as the proposal itself says at the end as the cons: - It's harder to read than the alternative. >- Creating a language extension

Re: Proposal: ArgumentDo

On Wed, Jul 6, 2016 at 10:39 AM, Bardur Arantsson wrote: > On 07/04/2016 12:31 PM, Akio Takano wrote: >> Hi glasgow-haskell-users, >> >> I have written a wiki page about a proposed extension called >> ArgumentDo. It's a small syntactic extension that allows "do" >>

Re: Proposal: ArgumentDo

On 07/04/2016 12:31 PM, Akio Takano wrote: > Hi glasgow-haskell-users, > > I have written a wiki page about a proposed extension called > ArgumentDo. It's a small syntactic extension that allows "do" > expressions, lambdas and a few other kinds of expressions to be used > as function arguments,

Re: Proposal: ArgumentDo

Hi, allowing group A constructs (do, case, ...) and group B constructs (\, let, if, ...) as parts of functions application (fexp) without extra parentheses looks natural to me. The current state is an artificial and unnecessary restriction. Style guides may dictate restrictions, but the

Re: Proposal: ArgumentDo

Infix ($) is so noisy that I’ve adapted a code style that replaces it entirely with parentheses. And the hack to make ($) work with higher-rank types is pretty awkward too. Seen from these angles, I’m very much in favour of ArgumentDo. However, the clarity of `runST do ...` comes at a high price:

Proposal: ArgumentDo

Hi glasgow-haskell-users, I have written a wiki page about a proposed extension called ArgumentDo. It's a small syntactic extension that allows "do" expressions, lambdas and a few other kinds of expressions to be used as function arguments, without parentheses.