Joe,
thanks for explaining.
> Option "A" is a lot cheaper in such an environment, because you just
> rerun the mini-parser when an external interface changes.
I'd rather go with Option B, though: It should be faster (parsing the
original source code is rather slow compared to traversing the generated
tree and looking for the right types) and it's more universal as we're first
building a more general tree which we then attribute with extra information.
With Option B, we also can see better what's left (e.g. all the identifiers
from the RB framework), filter them and recreate a table from that to use as
a prototype of the RB framework.
What do you and others think?
In any case, what should be the structure we're generating for the tree?
Does the one the TTsASTParser tries to generate make sense to you?
Basically, it uses separate classes for each type of grammar node, for
example it has a unique class for each possible operator. I think that's a
bit of overkill - I'd rather have a class for each of the operator
priorities (one for plus/minus/or, one for mul/div/and, one for comparisons,
one for not and negate, etc., and then add a property naming the particular
operator). That way, the hierarchy of operators is seen right in the tree.
Similarly, one class for all kind of loops, maybe, and a sub-class
identifying the different kinds of loops with their parameters. But maybe
this won't work because it requires that the code is free of errors such as
a missing "next". Maybe it's better that the initial tree is free of such
semantics?
Thomas
|
