ANNOUNCING Happy 1.15 - The LALR(1) Parser Generator for Haskell I'm pleased to announce version 1.15 of Happy, the parser generator system for Haskell. Changes from version 1.14 to 1.15 * New %expect directive * the list of tokens passed to happyError now includes the current token (not %lexer). * added support for ambiguous grammars via Generalized LR parsing * added %partial to indicate a parser that can return a result before EOF is reached. NOTE: Happy version 1.15 will be *required* for building newer versions of GHC, due to use of %partial in GHC's parser. If you build GHC from source, get this release, or build it from CVS. Happy is available in source form, which can be compiled with GHC version 5.04+, and we also provide binaries for some architectures. The Happy homepage with links to the various distributions lives at: http://www.haskell.org/happy/ Please send any bug reports and comments to simonmar@microsoft.com.
parser name directive
This has no effect at present. It will probably remain this way: if you want to control names, you could use qualified import. ... The driver file exports a function doParse :: [[UserDefTok]] -> GLRResult
Does this mean that it is not possible to put multiple entry points into a GLR parser? For example, I have a Happy 1.14 grammar that has rules "type," "expr," among others. How would I go about generating a "doParse" that will start at either of these rules? Do I have to do something like: allMyStartRules: expr | type | <other-start-rules> ; and then filter the GLRResult based on the "start rule" I wanted? Does the %partial directive work with GLR parsers too? Thanks, Brian
Hello,
Does this mean that it is not possible to put multiple entry points into a GLR parser?
Correct: the GLR parser doesn't provide this standard Happy functionality. There is the work-around that you mention. I decided to leave %name out this time, mainly because of the possibility of the workaround and because (I think) the issues are slightly different in the GLR setting (see below). But it's on the list to add next time, and shouldn't be too hard. The same for %partial. Note that a GLR parser will handle a top rule which allows any of your start symbols - ie, S/R and R/R conflicts won't be an issue as they would be for standard Happy. If you are using Tree-decode mode, the top-level rule will return values in some union of the separate parser results, and it's a simple matter to then pick out the ones you want. It's an open question whether this is better (since you can now do it), compared to deciding in advance what you expect and then trying to parse just that. Comments on this point are welcome! I'm also interested in examples where people want multiple entry points but want to work with graphs (rather than decoding them). Cheers, Paul
participants (3)
-
Brian Smith -
P.C.Callaghan -
Simon Marlow