Fixity

[Christian Maeder]

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
>