002 17:59
To: Simon Peyton-Jones
Subject: Re: H98 Report: expression syntax glitch
Simon,
> Ross points out that this is really hard to parse:
>
> | case x of y | ($ True) $ \ z -> z :: Bool -> Bool -> y
>
> because the parser doesn't know when to stop eating
Ross points out that this is really hard to parse:
| case x of y | ($ True) $ \ z -> z :: Bool -> Bool -> y
because the parser doesn't know when to stop eating the type
and treat the arrow as the case-alternative arrow.
Carl reminds us that this is hard to parse too:
| do a == b == c
"Simon Peyton-Jones" <[EMAIL PROTECTED]> writes:
> I didn't phrase it right. I meant that a let/lambda/if always
> extends to the next relevant (not part of a smaller expression)
> punctuation symbol; and if that phrase parses as an exp
> that's fine, otherwise it's a parse error. So I should
On Wed, Feb 27, 2002 at 06:45:45AM -0800, Simon Peyton-Jones wrote:
> So I propose to say that 'let', 'lambda' and 'if' productions have
> a side condition that (say)
> let .. in exp
> is syntactially valid only if the phrase is followed by one of the
> punctuation symbols
> ) ] }
On Mon, Feb 25, 2002 at 04:27:56PM -, Simon Marlow wrote:
>
> This is a known problem with the Haskell grammar. Another example in
> a similar vein is
>
> let x = 3 in x == 4 == True
>
> which should parse as
>
> (let x = 3 in x == 4) == True
>
> according to the "extends as
On Mon, Feb 25, 2002 at 04:30:24PM +, Malcolm Wallace wrote:
> > Yes, but it reports type errors for the variants
> > f x = (\x -> x*x .)
> > g x = (if x then 1 else 2 +)
> > and it accepts
> > h = (let op x y = y in 3 `op`)
> > so I suspect it's misparsing these as
> > f x = (
On Wed, Feb 27, 2002 at 04:00:39PM +0100, Arthur Baars wrote:
> In the context-free grammar proposed by Ross Paterson
> the following line:
> expix -> expi+1B [qop(n,i) expi+1x]
>
> should be replaced by
> expix -> [expi+1B qop(n,i)] expi+1x
Yes. (In fact that's what I had in the revised hs
--Original Message-
| From: Ross Paterson [mailto:[EMAIL PROTECTED]]
| Sent: 27 February 2002 10:43
| To: Simon Peyton-Jones
| Cc: [EMAIL PROTECTED]
| Subject: Re: H98 Report: expression syntax glitch
|
|
| On Tue, Feb 26, 2002 at 08:23:03AM -0800, Simon Peyton-Jones wrote:
| > I didn't p
On Tue, Feb 26, 2002 at 08:23:03AM -0800, Simon Peyton-Jones wrote:
> I didn't phrase it right. I meant that a let/lambda/if always
> extends to the next relevant (not part of a smaller expression)
> punctuation symbol; and if that phrase parses as an exp
> that's fine, otherwise it's a parse er
because
x `div`
isn't a exp.
Simon
| -Original Message-
| From: Ross Paterson [mailto:[EMAIL PROTECTED]]
| Sent: 26 February 2002 16:06
| To: Simon Peyton-Jones
| Cc: [EMAIL PROTECTED]
| Subject: Re: H98 Report: expression syntax glitch
|
|
| On Tue, Feb 26, 2002 at 07:30:44AM
On Tue, Feb 26, 2002 at 07:30:44AM -0800, Simon Peyton-Jones wrote:
> Replace "The ambiguity is resolved by the meta rule that each of these
> constructs extends as far to the right as possible" by
>
> "The ambiguity is resolved by the meta rule that each
> of these constructs extend
| Consider the following Haskell 98 expressions:
|
| (let x = 10 in x `div`)
| (let x = 10 in x `div` 3)
|
| To parse the first, a bottom-up parser should reduce the
| let-expression before the operator, while to parse the second
| it should shift. But it needs 4 tokens of lookahea
> On Mon, Feb 25, 2002 at 05:07:35PM -, Simon Marlow wrote:
> > On the other hand, one way to fix this problem *is* to specify the
> > relative precedence of 'let' & co. as compared to infix operators
> > (namely that 'let' should have a lower precedence). That would be a
> > reasonable fix
On Mon, Feb 25, 2002 at 05:07:35PM -, Simon Marlow wrote:
> On the other hand, one way to fix this problem *is* to specify the
> relative precedence of 'let' & co. as compared to infix operators
> (namely that 'let' should have a lower precedence). That would be a
> reasonable fix for the H98
> In the table of precedence in the original Report (now deleted in
> the revised Report), it makes it clear that a rightward-extending
> let, if, or lambda has a lower precedence than an infix operator,
> so for instance the parse
>
> h = (let op x y = y in (3 `op`))
>
> is correct and
>
> Yes, but it reports type errors for the variants
> f x = (\x -> x*x .)
> g x = (if x then 1 else 2 +)
> and it accepts
> h = (let op x y = y in 3 `op`)
> so I suspect it's misparsing these as
> f x = (\x -> (x*x .))
> g x = (if x then 1 else (2 +))
> h = (let
> Consider the following Haskell 98 expressions:
>
> (let x = 10 in x `div`)
> (let x = 10 in x `div` 3)
>
> To parse the first, a bottom-up parser should reduce the
> let-expression
> before the operator, while to parse the second it should shift.
> But it needs 4 tokens of lookahe
Ross's example reminds me of a problem I once reported about
the SML syntax. In Haskell, it is ambiguated, vaguely:
False && if undefined then undefined else undefined || True
...is what?
Apparently, it is False, on the grounds of the 'extends as far right
as possible' meta-rule for if/lambda/
On Mon, Feb 25, 2002 at 03:38:39PM +, Malcolm Wallace wrote:
> nhc98 manages to parse and compile both expressions with ease, no doubt
> because it uses parser combinators rather than a table-driven mechanism.
Yes, but it reports type errors for the variants
f x = (\x -> x*x .)
> (let x = 10 in x `div`)
> (let x = 10 in x `div` 3)
>
> To parse the first, a bottom-up parser should reduce the let-expression
> before the operator, while to parse the second it should shift.
> But it needs 4 tokens of lookahead to decide which to do. That seems
> unreasonable, an
Consider the following Haskell 98 expressions:
(let x = 10 in x `div`)
(let x = 10 in x `div` 3)
To parse the first, a bottom-up parser should reduce the let-expression
before the operator, while to parse the second it should shift.
But it needs 4 tokens of lookahead to decide wh
21 matches
Mail list logo
