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 > _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
