On Mon, Feb 08, 2010 at 04:59:59PM +0000, Ross Paterson wrote:

But I agree they should all be legal, i.e. that unary minus should bind more tightly than any infix operator (as in C).

See also http://hackage.haskell.org/trac/haskell-prime/wiki/NegativeSyntax Thanks Ian

Of course unary minus should bind tighter than any infix operator. I remember suggesting this when the language was designed, but the Haskell committee was very set against it (mostly Joe Fasel I think). I think it's too late to change that now, it could really introduce some subtle bugs with no parse or type errors. On Mon, Feb 8, 2010 at 5:59 PM, Ross Paterson wrote:

On Mon, Feb 08, 2010 at 04:18:07PM +0000, Simon Peyton-Jones wrote:

...

Which of these definitions are correct Haskell?

  x1 = 4 + -5   x2 = -4 + 5   x3 = 4 - -5   x4 = -4 - 5   x5 = 4 * -5   x6 = -4 * 5

Ghc accepts x2, x4, x6 and rejects the others with a message like Foo.hs:4:7:     Precedence parsing error         cannot mix `+' [infixl 6] and prefix `-' [infixl 6] in the same infix expression

Hugs accepts them all.

I believe that the language specifies that all should be rejected.  http://haskell.org/onlinereport/syntax-iso.html

I think GHC conforms to the Report; here is the relevant part of the grammar:

exp6    ->      exp7        |       lexp6 lexp6   ->      (lexp6 | exp7) + exp7        |       (lexp6 | exp7) - exp7        |       - exp7

exp7    ->      exp8        |       lexp7 lexp7   ->      (lexp7 | exp8) * exp8

But I agree they should all be legal, i.e. that unary minus should bind more tightly than any infix operator (as in C).  Note that Hugs does not do that:

Hugs> -5 `mod` 2 -1 Hugs> (-5) `mod` 2 1 Hugs> -(5 `mod` 2) -1 _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

| I imagine it would be something like deleting the production | | lexp6 -> - exp7

The rational for the current choice was the example: f x = -x^2

| and adding the production | | exp10 -> - fexp

But I would also recommend this change. It would also make sense to allow "-" before "let", "if" and "case" or another "-" expression, but that's a matter of taste. Cheers Christian

Lennart Augustsson wrote:

Of course unary minus should bind tighter than any infix operator. I remember suggesting this when the language was designed, but the Haskell committee was very set against it (mostly Joe Fasel I think).

Are there archives of this discussion anywhere? Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

But I agree they should all be legal, i.e. that unary minus should bind more tightly than any infix operator (as in C).

I'd just like to interject that I disagree, and think that the current behaviour is about as good as one could hope for. Negation is an additive operation, and thus has lower precedence than multiplication and exponentiation. -x^2 must be interpreted as -(x^2), not as (-x)^2. Similarly, though it seems to confuse some people, it makes more sense that - x `mod` y is parsed as - (x `mod` y) since mod has to do with multiplication, so it should bind more tightly than additive operations. - Cale

On Mon, Feb 08, 2010 at 01:24:55PM -0800, John Meacham wrote:

What would be the actual change proposed? If it is something concrete and not something like "negatives should be interpreted as unary minus when otherwise it would lead to a parse error" then that wouldn't be good. I have enough issues with the layout rule as is :)

I imagine it would be something like deleting the production lexp6 -> - exp7 and adding the production exp10 -> - fexp

On 10 Feb, 2010, at 00:53 , Lennart Augustsson wrote:

Do you deal with this correctly as well: case () of _ -> 1==1==True

No, that is, in the same way as GHC & Hugs, by reporting an error. The report acknowledges that compilers may not deal with this correctly when it has the form ``let x=() in 1=1=True'' (or a if/\... -> prefix), but does not do so for your example. It is even a bit more complicated of the layout rule because case () of _ -> 1==1 ==True is accepted. I think the combination of layout rule, ambiguity disambiguated by a 'extend as far as possible to the right' rule, fixity notation as syntax directives (but not separated as such), makes the language design at some points rather complex to manage implementationwise in a compiler. Like all we do our best to approach the definition. When possible I'd prefer changes in the language which simplify matters (like a simpler way of dealing with negate as proposed), at least with these syntactical issues.

On Tue, Feb 9, 2010 at 10:43 PM, S. Doaitse Swierstra

...

wrote: One we start discussing syntax again it might be a good occasion to reformulate/make more precise a few points.

The following program is accepted by the Utrecht Haskell Compiler (here we took great effort to follow the report closely ;-} instead of spending our time on n+k patterns), but not by the GHC and Hugs.

module Main where

-- this is a (rather elaborate) definition of the number 1 one = let x=1 in x

-- this is a definition of the successor function using section notation increment = ( one + )

-- but if we now unfold the definition of one we get a parser error in GHC increment' = ( let x=1 in x + )

The GHC and Hugs parsers are trying so hard to adhere to the meta rule that bodies of let-expressions extend as far as possible when needed in order to avoid ambiguity, that they even apply that rule when there is no ambiguity; here we have only a single possible parse, i.e. interpreting the offending expression as ((let x = 1 in ) +).

Yes, Haskell is both a difficult language to parse and to describe precisely.

Doaitse

On 8 feb 2010, at 17:18, Simon Peyton-Jones wrote:

...

Folks

Which of these definitions are correct Haskell?

x1 = 4 + -5 x2 = -4 + 5 x3 = 4 - -5 x4 = -4 - 5 x5 = 4 * -5 x6 = -4 * 5

Ghc accepts x2, x4, x6 and rejects the others with a message like Foo.hs:4:7: Precedence parsing error cannot mix `+' [infixl 6] and prefix `-' [infixl 6] in the same infix expression

Hugs accepts them all.

I believe that the language specifies that all should be rejected. http://haskell.org/onlinereport/syntax-iso.html

I think that Hugs is right here. After all, there is no ambiguity in any of these expressions. And an application-domain user found this behaviour very surprising.

I'm inclined to start a Haskell Prime ticket to fix this language definition bug. But first, can anyone think of a reason *not* to allow all the above?

Simon

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

- Atze - Atze Dijkstra, Department of Information and Computing Sciences. /|\ Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \ Tel.: +31-30-2534118/1454 | WWW : http://www.cs.uu.nl/~atze . /--| \ Fax : +31-30-2513971 .... | Email: atze@cs.uu.nl ............ / |___\

On Feb 9, 2010, at 10:43 PM, S. Doaitse Swierstra wrote:

-- but if we now unfold the definition of one we get a parser error in GHC increment' = ( let x=1 in x + )

The GHC and Hugs parsers are trying so hard to adhere to the meta rule that bodies of let-expressions extend as far as possible when needed in order to avoid ambiguity, that they even apply that rule when there is no ambiguity; here we have only a single possible parse, i.e. interpreting the offending expression as ((let x = 1 in ) +).

Despite the fact that there is a typo (second x is missing), I can think of two possible parses. Actually, my mental parser produced the second one: ((let x=1 in x)+) let x=1 in (x+) The Haskell report may exclude my mental parse because operator sections need to be parenthesised. Or are you arguing that in your example different possible parses have the same semantics for an arguably obvious reason and that this fact is relevant? Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.)

Possible Solution There is a reason why lexical analysis follows the maximal munch rule whereas a parser will follow the minimal munch rule which I won't discuss, a fact that many of you may thank me for. Stated simply, the two operations, lexical analysis and parsing, correspond to different paradigms. I have done work in this area. If the compiler is at some step following the maximal munch rule it is performing lexical analysis and not parsing. Herein, may lie the problem. What this means is that the Haskell language needs to be compiled in stages wherein there is at least one intermediate language that in turn is the subject of lexical analysis followed by parsing. If the Haskell language specification makes this clear, the problem may go away. -------------------------------------------------- From: "S. Doaitse Swierstra" Sent: 09 Tuesday February 2010 1443 To: "Haskell Prime" Subject: Re: Negation

One we start discussing syntax again it might be a good occasion to reformulate/make more precise a few points.

The following program is accepted by the Utrecht Haskell Compiler (here we took great effort to follow the report closely ;-} instead of spending our time on n+k patterns), but not by the GHC and Hugs.

module Main where

-- this is a (rather elaborate) definition of the number 1 one = let x=1 in x

-- this is a definition of the successor function using section notation increment = ( one + )

-- but if we now unfold the definition of one we get a parser error in GHC increment' = ( let x=1 in x + )

The GHC and Hugs parsers are trying so hard to adhere to the meta rule that bodies of let-expressions extend as far as possible when needed in order to avoid ambiguity, that they even apply that rule when there is no ambiguity; here we have only a single possible parse, i.e. interpreting the offending expression as ((let x = 1 in ) +).

Yes, Haskell is both a difficult language to parse and to describe precisely.

Doaitse

I don't think this is a bug. I do not expect to be able to unfold a definition without some syntactic issues. For example, two = 1+1 four = 2 * two but unfolding fails (four = 2 * 1 + 1). In general, we expect to have to parenthesize things when unfolding them. John On Feb 13, 2010, at 11:56 AM, Simon Marlow wrote:

On 09/02/10 21:43, S. Doaitse Swierstra wrote:

...

One we start discussing syntax again it might be a good occasion to reformulate/make more precise a few points.

The following program is accepted by the Utrecht Haskell Compiler (here we took great effort to follow the report closely ;-} instead of spending our time on n+k patterns), but not by the GHC and Hugs.

module Main where

-- this is a (rather elaborate) definition of the number 1 one = let x=1 in x

-- this is a definition of the successor function using section notation increment = ( one + )

-- but if we now unfold the definition of one we get a parser error in GHC increment' = ( let x=1 in x + )

Now that *is* an interesting example. I had no idea we had a bug in that area. Seems to me that it ought to be possible to fix it by refactoring the grammar, but I haven't tried yet.

Are there any more of these that you know about?

Cheers, Simon _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

On Sun, Feb 14, 2010 at 03:21:54AM +0100, Lennart Augustsson wrote:

I agree, I don't think this is a bug. If the grammar actually says that this is legal, then I think the grammar is wrong.

Then what do you think the grammar should say instead? That sections should be ( fexp qop ) ? I've never been keen on (1 * 2 +) actually; and I've just discovered that hugs doesn't accept it. Thanks Ian

On Sun, Feb 14, 2010 at 1:48 AM, John Launchbury wrote:

...

I don't think this is a bug. I do not expect to be able to unfold a definition without some syntactic issues. For example,

two = 1+1 four = 2 * two

but unfolding fails (four = 2 * 1 + 1). In general, we expect to have to parenthesize things when unfolding them.

John

On Feb 13, 2010, at 11:56 AM, Simon Marlow wrote:

...

On 09/02/10 21:43, S. Doaitse Swierstra wrote:

...

One we start discussing syntax again it might be a good occasion to reformulate/make more precise a few points.

The following program is accepted by the Utrecht Haskell Compiler (here we took great effort to follow the report closely ;-} instead of spending our time on n+k patterns), but not by the GHC and Hugs.

module Main where

-- this is a (rather elaborate) definition of the number 1 one = let x=1 in x

-- this is a definition of the successor function using section notation increment = ( one + )

-- but if we now unfold the definition of one we get a parser error in GHC increment' = ( let x=1 in x + )

Now that *is* an interesting example.  I had no idea we had a bug in that area. Seems to me that it ought to be possible to fix it by refactoring the grammar, but I haven't tried yet.

Are there any more of these that you know about?

In UHC it was unpleasant to make it work, because in (e) and (e +) it only is detected just before the closing parenthesis which of the two alternatives (i.e. parenthesized or sectioned expression) must be chosen. The use of LL parsing aggravates this somewhat, so the required left-factoring now takes into account everything that may be accepted between parenthesis in one parser (also (e1,e2,...), (e::t)), and then later on sorts out the correct choice; a 2-pass approach thus. For LR parsing I expect this to be simpler. However, because it concerns examples into which apparently few have stumbled, I'd be happy to follow Ian's suggestion that sections have the syntax: ( fexp qop ) I have no idea though how many programs will break on this. cheers, Atze On 14 Feb, 2010, at 09:32 , Simon Marlow wrote:

On 14/02/10 02:21, Lennart Augustsson wrote:

...

I agree, I don't think this is a bug. If the grammar actually says that this is legal, then I think the grammar is wrong.

As far as I can tell Doitse is correct in that GHC does not implement the grammar, so it's either a bug in GHC or the grammar. To fix it in the grammar would no doubt involve quite a bit of refactoring, I can't immediately see how to do it easily.

Cheers, Simon

...

On Sun, Feb 14, 2010 at 1:48 AM, John Launchbury wrote:

...

I don't think this is a bug. I do not expect to be able to unfold a definition without some syntactic issues. For example,

two = 1+1 four = 2 * two

but unfolding fails (four = 2 * 1 + 1). In general, we expect to have to parenthesize things when unfolding them.

John

On Feb 13, 2010, at 11:56 AM, Simon Marlow wrote:

...

On 09/02/10 21:43, S. Doaitse Swierstra wrote:

...

One we start discussing syntax again it might be a good occasion to reformulate/make more precise a few points.

The following program is accepted by the Utrecht Haskell Compiler (here we took great effort to follow the report closely ;-} instead of spending our time on n+k patterns), but not by the GHC and Hugs.

module Main where

-- this is a (rather elaborate) definition of the number 1 one = let x=1 in x

-- this is a definition of the successor function using section notation increment = ( one + )

-- but if we now unfold the definition of one we get a parser error in GHC increment' = ( let x=1 in x + )

Now that *is* an interesting example. I had no idea we had a bug in that area. Seems to me that it ought to be possible to fix it by refactoring the grammar, but I haven't tried yet.

Are there any more of these that you know about?

Cheers, Simon _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

S. Doaitse Swierstra schrieb:

weird :: Int -> Int weird = (if True then 3 else 5+)

is perfectly correct Haskell?

Yes, this is legal according to the grammar http://haskell.org/onlinereport/syntax-iso.html but rejected by ghc and hugs, because "5+" is illegal. The problem is to allow let-, if-, do-, and lambda-expressions to the left of operators (qop), because for those the meta rule "extend as far as possible" should apply. Switching to the new grammar http://hackage.haskell.org/trac/haskell-prime/wiki/FixityResolution infixexp -> exp10 qop infixexp | - infixexp | exp10 should be replaced by: infixexp -> fexp qop infixexp | exp10 (omitting the negate rule) or shorter: "infixexp -> { fexp qop } exp10" Left sections should look like: ( {fexp qop} fexp qop ) It would be even possible to avoid parenthesis around sections, because a leading or trailing operator (or just a single operator) uniquely determines the kind of expression. Negation should be added independently to fexp (and possibly to exp10, too) fexp -> [fexp] aexp (function application) minusexp -> fexp | - fexp infixexp -> minusexp qop infixexp | exp10 | - exp10 (unless some wants the old FORTRAN behaviour of unary "-" to bind weaker than infix multiplication and exponentiation.) Cheers Christian

let me try again to fix the issue. Apologies, if you mind. Christian Maeder schrieb:

S. Doaitse Swierstra schrieb:

...

weird :: Int -> Int weird = (if True then 3 else 5+)

is perfectly correct Haskell?

Yes, this is legal according to the grammar http://haskell.org/onlinereport/syntax-iso.html but rejected by ghc and hugs, because "5+" is illegal.

"5+" is illegal, but therefore neither ghc nor hugs only parse the "5" and assume that the if-then-else-expression is finished after this "5" and leave the "+" to form the section as ((if True then 3 else 5)+)

The problem is to allow let-, if-, do-, and lambda-expressions to the left of operators (qop), because for those the meta rule "extend as far as possible" should apply.

Do- and case-expressions do not fall in the same class than let-, if-, and lambda-expressions. An operator following let, if and lambda should be impossible because such an operator should belong to the last expression inside let, if and lambda. But do- and case- expressions are terminated by a closing brace. The point is, when this closing brace is inserted. weird2 m = (do m >>) Inserting "}" between "m" and ">>" because "m >>" is illegal, leads to the same problem as above for if-then-else. "}" should be inserted before the ")". hugs and ghc fail because they expect an fexp following ">>".

Switching to the new grammar http://hackage.haskell.org/trac/haskell-prime/wiki/FixityResolution

infixexp -> exp10 qop infixexp | - infixexp | exp10

should be replaced by:

infixexp -> fexp qop infixexp | exp10

(omitting the negate rule)

or shorter: "infixexp -> { fexp qop } exp10"

Assuming that braces are properly inserted, my above (too restrictive) rule can be extended to include case- and do-expressions to "cdexp" (in order to allow operators between them): cdexp -> fexp | - fexp (negation) | do { stmts } | case exp of { alts } exp10 -> cdexp | \ apat1 ... apatn -> exp (n>=1) | let decls in exp | if exp then exp else exp infixexp -> cdexp qop infixexp | exp10 (or: infixexp -> { cdexp qop } exp10")

Left sections should look like:

( {fexp qop} fexp qop )

It would be even possible to avoid parenthesis around sections, because a leading or trailing operator (or just a single operator) uniquely determines the kind of expression.

The need to put sections into parenthesis is one cause for the current confusion. Inside the parenthesis the following expressions "iexp" are expected: iexp -> qop (operator turned to prefix-function) | infixexp (parenthesized expression) | infixexp :: [context =>] type (parenthesized typed expression) | qop infixexp (right section) | { cdexp qop } cdexp qop (left section) So another solution would be, to make such expression globally legal in the grammar and reject a single operator, left-, and right sections during a separate infix analysis in a similar way as "a == b == c" is first fully parsed but rejected later, because "==" is non-associative. In fact any (non-empty) sequence of qop and exp10 expressions could be made a legal expression (for the parser only) that is further subject to infix resolution. (This would for example also allow outfix operators via: iexp -> qop { cdexp qop } | ... if desirable for haskell prime.) Is this better now? Cheers Christian

Negation should be added independently to fexp (and possibly to exp10, too)

fexp -> [fexp] aexp (function application) minusexp -> fexp | - fexp

infixexp -> minusexp qop infixexp | exp10 | - exp10

(unless some wants the old FORTRAN behaviour of unary "-" to bind weaker than infix multiplication and exponentiation.)

Cheers Christian