
Hi all, The code below defines a ReadP parser which can parse either a keyword "wrapper" or an arbitrary identifier. I was hoping that it would give the output (CWrapper1,"") (CWrapper2,"") (CFunction "wrapper","") but it actually gives (CWrapper2,"") (CFunction "wrapper","") (CWrapper1,"") i.e. completed parses are returned before the parse that needs to "look" at the remaining input. I can see the logic behind the current behaviour, but in this case at least it's quite inconvenient. What do you think? Did I miss a better way to solve the problem? Should the behaviour be changed? If so, is changing it easy? import Data.Char import Control.Applicative ((<$>)) import Text.ParserCombinators.ReadP as ReadP main :: IO () main = mapM_ print test test :: [(CImportSpec, String)] test = readP_to_S parse "wrapper" where parse = do r <- choice [ token "wrapper" >> return CWrapper1, string "wrapper" >> return CWrapper2, CFunction <$> many1 (satisfy isAlpha) ] eof return r token str = do _ <- string str toks <- look case toks of c : _ | isAlpha c -> pfail _ -> return () data CImportSpec = CFunction String | CWrapper1 | CWrapper2 deriving Show Thanks Ian

On Sat, Feb 25, 2012 at 5:21 PM, Ian Lynagh
Hi all,
The code below defines a ReadP parser which can parse either a keyword "wrapper" or an arbitrary identifier. I was hoping that it would give the output (CWrapper1,"") (CWrapper2,"") (CFunction "wrapper","") but it actually gives (CWrapper2,"") (CFunction "wrapper","") (CWrapper1,"") i.e. completed parses are returned before the parse that needs to "look" at the remaining input.
I can see the logic behind the current behaviour, but in this case at
least it's quite inconvenient.
What do you think? Did I miss a better way to solve the problem? Should the behaviour be changed? If so, is changing it easy?
This is because ReadP is breadth first and the results are returned as they are determined. Can you get away with switching to (<++) , which will let you more or less pretend you are using a biased parser like parsec and will only give you the single result you want? Any change to ReadP that sorts the current breadth-first search state is going to incur an asymptotic increase in overhead when you have multiple parses and I don't think it would be a good idea. -Edward
participants (2)
-
Edward Kmett
-
Ian Lynagh