--- "Juan M. Duran" <[EMAIL PROTECTED]> wrote:
> Hi, I'm writting a small parser in Haskell and, when
> it is all done, I get
> the following problem: Type Binding.
>
> The thing is, I have 3 main functions:
> 1) Read the file, its type is: [Char] ->IO [Char]
> (see InputOutput.hs)
> 2) Parse a s
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
Hi, I'm writting a small parser in Haskell and, when it is all done, I get
the following problem: Type Binding.
The thing is, I have 3 main functions:
1) Read the file, its type is: [Char] ->IO [Char] (see InputOutput.hs)
2) Parse a string (using words and readDec), its type is: Integral a =>
[Ch
> 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
The following email address, "[EMAIL PROTECTED]" has been removed from the Verba
Volant Newsletter list.
If you did not cancel your email address or you wish to continue receiving Verba
Volant, please send an e-mail to [EMAIL PROTECTED]
Thank you and best regards,
Verba Volant
___
> Using FiniteMap, I often run into robustness problems.
same (?) here! a student of mine recently came across a similar problem
(with a hand-made search tree): he expected to run
listToFM $ [(0, ()) | i <- [0..10]]
in constant space, but instead it took all the stack and/or heap.
we ma
I had meant to send this message to the Haskell list, because I think
there may be some readers who have good ideas about it.
Simon
-Original Message-
From: Simon Peyton-Jones [mailto:[EMAIL PROTECTED]]
Sent: 20 February 2002 21:16
To: Patrik Jansson; Haskell Cafe List
Cc: Ralf Hinze; J
13 matches
Mail list logo
