On 10 Feb, 2010, at 00:53 , Lennart Augustsson wrote:
Do you deal with this correctly as well:
case () of _ -> 1==1==True
No, that is, in the same way as GHC & Hugs, by reporting an error. The
report acknowledges that compilers may not deal with this correctly
when it has the form ``let x=() in 1=1=True'' (or a if/\... ->
prefix), but does not do so for your example. It is even a bit more
complicated of the layout rule because
case () of _ -> 1==1
==True
is accepted.
I think the combination of layout rule, ambiguity disambiguated by a
'extend as far as possible to the right' rule, fixity notation as
syntax directives (but not separated as such), makes the language
design at some points rather complex to manage implementationwise in a
compiler. Like all we do our best to approach the definition. When
possible I'd prefer changes in the language which simplify matters
(like a simpler way of dealing with negate as proposed), at least with
these syntactical issues.
On Tue, Feb 9, 2010 at 10:43 PM, S. Doaitse Swierstra <doai...@cs.uu.nl
> 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 + )
The GHC and Hugs parsers are trying so hard to adhere to the meta
rule that
bodies of let-expressions
extend as far as possible when needed in order to avoid ambiguity,
that they
even apply that rule when there is no ambiguity;
here we have only a single possible parse, i.e. interpreting the
offending
expression as ((let x = 1 in ) +).
Yes, Haskell is both a difficult language to parse and to describe
precisely.
Doaitse
On 8 feb 2010, at 17:18, Simon Peyton-Jones wrote:
Folks
Which of these definitions are correct Haskell?
x1 = 4 + -5
x2 = -4 + 5
x3 = 4 - -5
x4 = -4 - 5
x5 = 4 * -5
x6 = -4 * 5
Ghc accepts x2, x4, x6 and rejects the others with a message like
Foo.hs:4:7:
Precedence parsing error
cannot mix `+' [infixl 6] and prefix `-' [infixl 6] in the
same infix
expression
Hugs accepts them all.
I believe that the language specifies that all should be rejected.
http://haskell.org/onlinereport/syntax-iso.html
I think that Hugs is right here. After all, there is no ambiguity
in any
of these expressions. And an application-domain user found this
behaviour
very surprising.
I'm inclined to start a Haskell Prime ticket to fix this language
definition bug. But first, can anyone think of a reason *not* to
allow all
the above?
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
- Atze -
Atze Dijkstra, Department of Information and Computing Sciences. /|\
Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \
Tel.: +31-30-2534118/1454 | WWW : http://www.cs.uu.nl/~atze . /--| \
Fax : +31-30-2513971 .... | Email: a...@cs.uu.nl ............ / |___\
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
