From: joel de guzman (joel_at_[hidden])
Date: 2001-05-21 18:47:01
From: "Larry Evans" :
> From http://www20.brinkster.com/djowel/spirit_doc.html#N5, I'm inferring
> analysis of the grammar (e.g. to calculate the first or follow sets
> [ohttp://www.antlr.org/papers/pcctsbk.pdf, p.27] of a non-terminal)
> is done. In other words, the code just keeps parsing and back-tracking
> until it finds a match. Is that right? If so, then it would obviously be
> than yacc or an LL(1) parser. On the other hand, this would be OK for
> languages or files, I guess.
Perhaps you are right. Yet in many occasions ambiguities does not
ever span the whole input, typically, a line, if most a block. C/C++
come to mind. Also, you really have to hack yacc to parse ambiguous grammars
and LL(1) cannot have ambiguities past 1 token.
> I'm also wondering about the scanner. Could the scanner actually be
> instance of the parser. For example, I'd like to use some sort of
> to specify the scanner. For example, one scanner may just return tokens,
> may return AST's. Is this possible with SPIRIT?
Theoretically yes. I designed spirit to be blur the distinction between a
scanner (character level) and a parser (phrase level). The scanner 'has-a'
white-space-parser that can accept an arbitrarily complex parser. It
can parse comments, pragmas in addition to spaces, tabs and new lines
A performance issue I am more concerned of is the lexical analysis. A
conventional lexer pre-scans the input. Yet this can be solved by having
layers for pre-processing, lexing and parsing, which can of course be
done using spirit.
Thanks for your comments.
Joel de Guzman
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk