Boost logo

Boost :

From: joel de guzman (joel_at_[hidden])
Date: 2001-05-21 18:47:01

From: "Larry Evans" :

> From, I'm inferring
that no
> analysis of the grammar (e.g. to calculate the first or follow sets
> [o, 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
much slower
> 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
template argument
> to specify the scanner. For example, one scanner may just return tokens,
but another
> 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
for example.

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, gregod at, cpdaniel at, john at