Negation

[Atze Dijkstra]

In UHC it was unpleasant to make it work, because in (e) and (e +) it  
only is detected just before the closing parenthesis which of the two  
alternatives (i.e. parenthesized or sectioned expression) must be  
chosen. The use of LL parsing aggravates this somewhat, so the  
required left-factoring now takes into account everything that may be  
accepted between parenthesis in one parser (also (e1,e2,...), (e::t)),  
and then later on sorts out the correct choice; a 2-pass approach  
thus. For LR parsing I expect this to be simpler.

However, because it concerns examples into which apparently few have  
stumbled, I'd be happy to follow Ian's suggestion that sections have  
the syntax:

   ( fexp qop )

I have no idea though how many programs will break on this.

cheers,
Atze

On  14 Feb, 2010, at 09:32 , Simon Marlow wrote:

> On 14/02/10 02:21, Lennart Augustsson wrote:
>> I agree, I don't think this is a bug.  If the grammar actually says
>> that this is legal, then I think the grammar is wrong.
>
> As far as I can tell Doitse is correct in that GHC does not  
> implement the grammar, so it's either a bug in GHC or the grammar.   
> To fix it in the grammar would no doubt involve quite a bit of  
> refactoring, I can't immediately see how to do it easily.
>
> Cheers,
> 	Simon
>
>>
>> On Sun, Feb 14, 2010 at 1:48 AM, John Launchbury<john at galois.com>   
>> wrote:
>>> I don't think this is a bug. I do not expect to be able to unfold  
>>> a definition without some syntactic issues. For example,
>>>
>>> two = 1+1
>>> four = 2 * two
>>>
>>> but unfolding fails (four = 2 * 1 + 1). In general, we expect to  
>>> have to parenthesize things when unfolding them.
>>>
>>> John
>>>
>>>
>>> On Feb 13, 2010, at 11:56 AM, Simon Marlow wrote:
>>>
>>>> On 09/02/10 21:43, S. Doaitse Swierstra wrote:
>>>>> One we start discussing syntax again it might be a good occasion  
>>>>> to
>>>>> reformulate/make more precise a few points.
>>>>>
>>>>> The following program is accepted by the Utrecht Haskell  
>>>>> Compiler (here
>>>>> we took great effort to follow the report closely ;-} instead of
>>>>> spending our time on n+k patterns), but not by the GHC and Hugs.
>>>>>
>>>>> module Main where
>>>>>
>>>>> -- this is a (rather elaborate) definition of the number 1
>>>>> one = let x=1 in x
>>>>>
>>>>> -- this is a definition of the successor function using section  
>>>>> notation
>>>>> increment = ( one + )
>>>>>
>>>>> -- but if we now unfold the definition of one we get a parser  
>>>>> error in GHC
>>>>> increment' = ( let x=1 in x + )
>>>>
>>>> Now that *is* an interesting example.  I had no idea we had a bug  
>>>> in that area. Seems to me that it ought to be possible to fix it  
>>>> by refactoring the grammar, but I haven't tried yet.
>>>>
>>>> Are there any more of these that you know about?
>>>>
>>>> Cheers,
>>>>      Simon
>>>> _______________________________________________
>>>> Haskell-prime mailing list
>>>> Haskell-prime at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/haskell-prime
>>>
>>> _______________________________________________
>>> Haskell-prime mailing list
>>> Haskell-prime at haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-prime
>>>
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime