# fixity resolution

Simon Marlow marlowsd at gmail.com
Wed Jul 7 10:02:19 EDT 2010

```On 06/07/2010 18:12, Christian Maeder wrote:
>
> "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

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
```