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<j...@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@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
