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,
> Now that you're an (ahem) Microsoft employee, is there any
> intention of
> allowing ghc to use Visual C++ instead of gcc,
We plan to allow this, but there'll be a price to pay: the gcc extensions
that we use buy us about a factor of 2 in performance and binary sizes.
> or supporting the Win3
> 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)
10 matches
Mail list logo
