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
>
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 i
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
Christian Sievers <[EMAIL PROTECTED]> writes:
> I changed my mind about this issue, I do suggest to change it as
> proposed, for if `elem` were three lexemes, any whitespace between
> them would be allowed. This might even be considered a typo, as I
> think no one intended to allow expressions li
Carl Witty wrote about layout horror and reasoned that
>do { a `elem` b `
> is a legal prefix of the Haskell grammar: it could be completed by
>do { a `elem` b `seq` c }
> for instance. So no implicit close-brace gets inserted; and
>a `elem` b `elem` c
> is a syntax error.
which see
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.
> 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 h
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 t
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
Lennart Augustsson <[EMAIL PROTECTED]> wrote,
> "Carl R. Witty" 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
> > thi
[EMAIL PROTECTED] (Carl R. Witty) wrote,
> "Manuel M. T. Chakravarty" <[EMAIL PROTECTED]> writes:
>
> > 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 w
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 fi
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 (unles
| 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 difficult,
> 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
implementa
> 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)
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
"Carl R. Witty" 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.)
I think you're absolutely right. And I can't ima
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!!) th
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 particu
"Manuel M. T. Chakravarty" <[EMAIL PROTECTED]> writes:
> 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
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 particu
22 matches
Mail list logo
