On Fri, Mar 19, 2010 at 11:21 AM, Brandon S. Allbery KF8NH
On Mar 19, 2010, at 11:14 , Derek Thurn wrote:
Here's a simplified version of my grammar:
myType = try (primitiveType) <|> arrayType primitiveType = do {reserved "int"; return "primitive"} arrayType = do { primitiveType; symbol "["; symbol "]"; return "array"}
What you're doing here is matching and succeeding on primitiveType and never even looking for the bracket; your parser then exits and the framework fails expecting the end of the token stream but finding the unmatched left bracket.
You need to rearrange your cases:
myType = try arrayType <|> primitiveType
so that your parser actually checks for the brackets before concluding that it has a primitiveType already.
Even better would be to refactor the grammar since both types start with a primitiveType, but I'll leave that up to you since it does complicate returning the shape of the resulting type.
-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
Ah, I see. The problem is that the primitiveType parser succeeds. Is there then no generic way to use lookahead in Parsec to make choices of this nature? I appreciate that it might be possible to refactor my grammar to never require examining the next token to make a parsing decision about the current token, but I've already got an LALR(1) grammar that I'm pretty happy with... What I'd ideally like is some sort of general solution wherein Parsec first tries primitiveType, moves to the next token, realizes that it will be a parse error, and backtracks to try the other alternative.