fixity resolution

[Christian Maeder]

Simon Marlow schrieb:
>> 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 -).

it is legal as funlhs (ghc-6.12.3)!

1 * - 1 = 2


Main> 1 Main.* (-1)
2

see also:
http://hackage.haskell.org/trac/ghc/ticket/4176

Christian

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