Warp wrote:
>   As I said above, this kind of abstraction makes it easier to enhance
> the parser. For example, support for a new type of input file format
> could be added completely transparently. The rest of the code doesn't
> even need to know this.

Abstraction on the syntactic analysis level says nothing about abstraction
on the lexical analysis level. As those two are distinct, passes, and hence
design choices of the parser do not influence the design of the lexical
analysis. I thought it was clear that when we talk about "parser" here, we
talk about it in the was it is used in POV-Ray, which means syntactic and
semantic analysis.

>   Adding support for new blocks is easy: Just create a new module and
> "plug it in" the parser.

This already works with the current parser. Only token names are kept in a
central file, because they are needed external to the parser, i.e. to
support syntax coloring. This could be handled differently though, so it
does not influence the level of "abstraction".

>   You say that this kind of system would require a large amount of
> chained virtual function calls. I don't see why this would be so.
> I can't think of any reason why this would be so.

I never said this at all. I said you need to divide each rule into methods,
which in and by itself is the problem. The overhead when they called is not
a problem I am talking about.

	Thorsten

Post a reply to this message