fixity resolution

[Simon Marlow]

On 07/07/2010 15:56, Christian Maeder wrote:
> 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

Well, that's a bug in GHC, not the Haskell report :-)

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

Thanks for reporting it.

Cheers,
	Simon



> 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