fixity resolution

[Simon Marlow]

On 06/07/2010 18:12, Christian Maeder wrote:
> 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."
>
> The string "1 * - 1" is legal as pattern, but rejected as expression!

Well, it's not a pattern (* is a varop, not a conop), and it's an 
illegal funlhs (* has greater precedence than prefix -).

> 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
> 	| 	( funlhs ) apat { apat }
>
>
> "a : b * c : d = undefined" is currently rejected with:
>
> "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").

The grammar specifies a superset of the language; fixity resolution may 
reject something that is legal according to the grammar.  That's the 
change we made in Haskell 2010: the grammar no longer attempts to 
describe the language precisely with respect to fixity resolution, for 
good reasons 
(http://hackage.haskell.org/trac/haskell-prime/wiki/FixityResolution).

See section 4.4.3.1  Function bindings:

"
Note that fixity resolution applies to the infix variants of the 
function binding in the same way as for expressions (Section 10.6). 
Applying fixity resolution to the left side of the equals in a function 
binding must leave the varop being defined at the top level. For 
example, if we are defining a new operator ## with precedence 6, then 
this definition would be illegal:
   a ## b : xs = exp

because : has precedence 5, so the left hand side resolves to (a ## x) : 
xs, and this cannot be a pattern binding because (a ## x) is not a valid 
pattern.
"


Perhaps this could be clearer, please do suggest improvements.


> P.S. like in my proposal for infixexp I would change pat to:
>
> pat 	 → 	pat qconop pat     	 (infix constructor)
> 	| 	lpat

is there any need to do that?  The grammar is non-ambiguous right now.

Cheers,
	Simon