Bug in Parser Combinators?

[Nick Kallen]

>I ran your parser program. I had to take <@ out of the definition of digit
>to prevent a compile error.

I haven't the slightest clue what causes the compile error--it runs fine on
my machine..

>I found two differences between your version of the Parsers and the one
>as I copied it from the book. First, your definition of <*>:

><*> :: (Parser s a) -> Parser s [a]
><*> p = (p <:&> <*> p)

You left out a line from my implementation of <*>:
<|> epsilon <@ (\_ -> [])

Above is exactly how the book does it. I used to have it as just (<|>
epsilon)
which has the same meaning, I think. (the lambda expression is pretty
redundant). This also has the same meaning as (<|> succeed []), but I think
(<|> epsilon is the more elegant solution.
    The only reason I changed it to mimick the book was in trying to debug
this digit program.

Both have the same meaning as far as I can tell the

>Your definition of satisfy:
>satisfy :: (s -> Bool) -> Parser s s
>satisfy f = p
>where
>  p [x:xs]
>   | f x = [(xs, x)]
>   | otherwise = []
>
>Mine:
>satisfy :: (s->Bool) (s->t) -> Parser s t
>satisfy f g = p
>where   p [x:xs] | f x  = [(xs,g x)]
>        p _                             = []
>
>You don't have a provision for empty input lists.

You're right! I think this solves the problem!!

>Your taking out (s->t) and leaving it to <@ may be a good idea,

I think this way is more orthogonal.


Thankyou!