patch applied (ghc): Fix a bug in alternative layout rule

Simon Marlow marlowsd at gmail.com
Tue Dec 1 04:02:55 EST 2009


On 30/11/2009 23:05, Duncan Coutts wrote:
> On Mon, 2009-11-30 at 17:26 +0000, Ian Lynagh wrote:
>> On Mon, Nov 30, 2009 at 11:12:36AM +0000, Duncan Coutts wrote:
>
>>> Hmm, 'where' is a keyword though, so can't that be done at the lexical
>>> level without having to tangle it with the parsing?
>>
>> I think it would be possible to have a special rule for this case, but
>> it would be an odd rule in my opinion. I'm not sure it would be possible
>> to explain why we had the rule, other than "because Haskell 98 behaved
>> that way".
>
> Yep, I'm happy with the H98 way :-)
>
>> Out of interest, without trying it, what do you think this program
>> should print (the only difference between the 3 functions is the
>> indentation of the "where" line)?:
>>
>> main = do print $ f1 1
>>            print $ f2 1
>>            print $ f3 1
>
> 10
> 10
> 6
>
>> f1 x = x + case () of
>>             () ->  x
>>           where x = 5
>
> 10 because, the where clause belongs to the top level of the function
> and names defined in a where clause mask the function parameters.
>
>> f2 x = x + case () of
>>             () ->  x
>>             where x = 5
>
> 10, same reason.

No, the only way to understand this example is by the mechanics of the 
layout translation.  Layout inserts a ';' before the 'where', because 
the 'where' lines up with the current layout context started by the 
'()'.  Now, 'where' is not a valid way to start a pattern, so the 
parse-error rule kicks in, and inserts a '}', after which the 'where' is 
valid in the context of the outer function.

Clearly this is not ideal at all.  We don't want users to have to reason 
in this way in order to understand how their code is parsed.

Cheers,
	Simon



More information about the Cvs-ghc mailing list