fixity resolution

[Christian Maeder]

Christian Maeder schrieb:
> http://www.haskell.org/~simonmar/haskell-2010-draft-report-2/haskellch10.html#x17-17300010
> 
> "Fixity resolution also applies to Haskell patterns, but patterns are a
> subset of expressions so in what follows we consider only expressions
> for simplicity."

I suggest to change "also applies to Haskell patterns" to

"also applies to Haskell patterns and left hand sides of infix function
bindings"

> The string "1 * - 1" is legal as pattern, but rejected as expression!

Further points:

1. "- 1 * 1" is accepted as legal pattern, but differently resolved for
expressions! Should one not reject these (rare) patterns, too?

2. I would rather allow "1 * - 1" and "1 + - 1" to be legal as
expressions (with its unambiguous interpretation).

3. Associativity should not matter for the non-binary "-"!

So the following resolutions are possible:

"1 + - 2 + 3" ~~~> "(1 + -2) + 3"
"1 + - 2 * 3" ~~~> "1 + -(2 * 3)"

infix 6 ##  -- same precedence like "+" but different associativity

"- 1 ## 2" ~~~> "(-1) ## 2"

An infix-expression following an unary minus is resolved independently
first. If the top-level operator has a strictly higher precedence than
"-" its resolved as minus term, otherwise the same procedure is applied
to the left argument of the infix expression. (If the left argument is
no infix expression, we are done by plain prefix application of minus.)

> 
> Furthermore fixity resolution does not distinguish between constructors
> and other operators as it should according to the grammar:
> 
> pat 	 → 	lpat qconop pat     	 (infix constructor)
> 	| 	lpat
> 
> 
> funlhs 	 → 	var apat { apat }
> 	| 	pat varop pat

add a description:
	|	pat varop pat		(infix binding)

> 	| 	( funlhs ) apat { apat }
> 
> 
> "a : b * c : d = undefined" is currently rejected with:

A similar example is given in 4.4.3.1  Function bindings. It should be
referenced in 10.6  Fixity Resolution

Cheers Christian

> 
> "cannot mix `:' [infixr 5] and `Main.*' [infixl 9] in the same infix
> expression"
> 
> but should be fine by the given grammar (rule "pat varop pat").
> 
> Cheers Christian
> 
> P.S. like in my proposal for infixexp I would change pat to:
> 
> pat 	 → 	pat qconop pat     	 (infix constructor)
> 	| 	lpat
> 
> for the sake of a better presentation only.