Simon Marlow wrote:
Does it mean that the following expressions would be illegal?
if cond then do proc1; proc2 else do proc3; proc4
(case e of Just x - x 0; Nothing - False)
Unfortunately, yes.
Now one can forget about {} and use layout everywhere. He would no
longer be able
I wrote:
lexeme - qvarid | qconid | qvarsym | qconsym
| literal | special | reservedop | reservedid
Now we could replace qvarsym and qconsym by qop, and have both
examples parse in the same way. However, unlike the other change in
lexeme's definition, I don't suggest this, I
As an author of an Haskell Emacs mode that deals with the layout rule
(described in Journal of Functional Programming 8(5) 493-502), I
strongly agree that the "parse-error condition" is really a bad idea.
For example, in Emacs, no full Haskell parse is done.
After all, layout should be there to
Simon Marlow [EMAIL PROTECTED] wrote,
Does anybody disagree with my interpretation of the standard? Are
there any implementations that actually follow the standard here?
(Maybe the standard should be changed to follow the implementations in
this area.)
Phew. Well spotted. Of
Does it mean that the following expressions would be illegal?
if cond then do proc1; proc2 else do proc3; proc4
(case e of Just x - x 0; Nothing - False)
Unfortunately, yes.
Now one can forget about {} and use layout everywhere. He would no
longer be able to forget or he would have to
Simon Peyton-Jones [EMAIL PROTECTED] writes:
In other words, it is a bug (and GHC and Hugs don't do it
right - see my previous message; from your comment, I
presume HBC also doesn't follow the definition). I think,
the only Right Thing is to remove this awful rule (unless
In other words, it is a bug (and GHC and Hugs don't do it
right - see my previous message; from your comment, I
presume HBC also doesn't follow the definition). I think,
the only Right Thing is to remove this awful rule (unless
somebody comes up with a rule that can be decided locally).
| How about the Carl Witty's
|
| do a == b == c
|
| does NHC handle this correctly?
It matches ghc and Hugs, reporting
Error when renaming:
Infix operator at 2:21 is non-associative.
Note that this is reported one stage *after* parsing. Because parsing
of infix operators is
Malcolm Wallace wrote:
Because parsing
of infix operators is difficult, all implementations (to my knowledge)
leave resolution of fixity and associativity until later. Indeed, the
Haskell 98 standard recognises this (in an oblique way) by permitting
infix decls to appear *after* the first
Does anybody disagree with my interpretation of the standard? Are
there any implementations that actually follow the standard here?
(Maybe the standard should be changed to follow the implementations in
this area.)
Phew. Well spotted. Of course, none of the existing Haskell
Fri, 30 Jul 1999 05:12:51 -0700, Simon Marlow [EMAIL PROTECTED] pisze:
The main reason for its inclusion was to allow things like
let f x = x in ...
and also to automatically insert the final '}' before the end of file.
Perhaps the layout rule should be restricted to these two
Malcolm Wallace [EMAIL PROTECTED] wrote,
[...]
Simon Marlow replies:
GHC and Hugs both make use of yacc-style error recovery, albeit in a very
limited form.
And nhc uses parser combinators, which give you backtracking on error
conditions for free. We actually do almost all layout
Manuel Chakravarty writes:
What kind of implementation did the originators of this
clause envision? If the layout rule is really implemented
as a filter between the scanner and the parser, it seems
extremely awkward to add a dependency on the error condition
of the parser - in particular,
One of our students just pointed out an IMHO rather
problematic clause in the layout rule. In Section 2.7 of
the Haskell 98 Report it says,
A close brace is also inserted whenever the syntactic
category containing the layout list ends; that is, if an
illegal lexeme is encountered at a
This is a multi-part message in MIME format.
--F93F7E72348E2F23CC7D1D40
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Manuel says
One of our students just pointed out an IMHO rather problematic clause in the
layout rule ... So, I guess (I hope!!)
Manuel Chakravarty writes:
What kind of implementation did the originators of this
clause envision? If the layout rule is really implemented
as a filter between the scanner and the parser, it seems
extremely awkward to add a dependency on the error condition
of the parser - in particular,
If the scanning stage pairs the tokens it returns with
their positions, then scanning can be done once before
parsing begins. I've done this with a parser implemented
with parser combinators, these combinators then decide
whether or not to accept a token based on which token
it is and how far it
17 matches
Mail list logo
