What exactly is the discerning aspect of a leaf. It seems that not having a child is not enough. Is there set of token types (or something else) that makes a leaf.
You automatically assume any source token to be a leaf. Is that enough?
IOW, Does that mean any node that has a token type other than ttNone is a leaf?
I am trying to fold TSourceToken back to TParseTreeNode, that is why I need to know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In general computer-science terms, a leaf node is any node with no children.
In this particular parse tree, all leaf nodes, and only leaf nodes, are source tokens. Non-leaf nodes represent groupings of source tokens, e.g. "expression", "case statement", "procedure", or "implementation section". See ParseTreeNodeType for the list of these types.
In the registry settings, select the "always show parse tree" radio, and you'll see the parse tree data displayed on a tree view.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From what I gather, TParseTreeNode and TSourceToken are basically the same thing (with TSourceTokenList thrown in to confuse the outsiders).
TSourceToken.NextToken is the same as TParseTreeNode.NextLeaf; same goes for TSourceToken.PriorToken().
These are basically functions calling functions and doing nothing other than wasting time in the process.
IOW, all are nodes, some are slightly different from others.
I would fold the two class into one. For simplicity and clarity.
I have not seen the latest CVS yet, this is based on the impressions before that:
TParseTreeNode.VisitTree() is an unnecessarily convoluted way of doing things. TXXVisitor already has a reference to the node in question. Why cant TXXVisitor directly do whatever is being done by this TParseTreeNode.VisitTree() ? It sure can. ANd, it is a lit more sensible, IMHO.
And then you would not need TVisitResult baggage of anomaly carried around all the time.
BTW, why were the elements of TVisitResult not properties of TXXVisitor I'll never know. But, anyway, that too is not important once TXXVisitor directly manipulates the Nodes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, the code that I checked in yesterday, and which is 10% faster, does away with the interface on the visitor, and with TParseTreeNode.VisitTree.
That code is now in a singleton class, TTreeWalker, which knows about both parse trees and visitors (technically they aren't the visitor pattern anymore).
This code could move into TBaseTreeNodeVisitor, but I haven't decided if that would be an advantage yet.
TRVisitResult works as before, since the visitor classes haven't changed. Much.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Some information has to come back from the visit. The bare minimum here is a Boolean to tell if the items at or before the current have been disturbed. There is a loop through the parent node's children, done now in TTreeWalker.VisitTree:
liLoop := 0;
while liLoop < pcNode.ChildNodeCount do
begin
lcChildNode := pcNode.ChildNodes[liLoop];
// lcChildNode is visited...
The problem is that when the child node is a source token that is deleted or has token inserted before it, liLoop is not valid any more. We don't want to check it every time, for speed reasons, so need to know when it has changed.
I have managed to do away with the aInsertAfter action by adding
IndexOfSelf: An expensive operation. It searches for itself in the parent list to find out its own index. ANd, this is an indirect call too --i.e. more than one function call. You dont use IndexOf() in an engine. It is reserved for GUI usage :-)
InsertChild(): Another expensive call. Internally, it searches for that index. Moves all the other items one cell further. Inserts the item...
Why all this?.. Just because we are stuck with TObjectList crap..
I must be getting on your nerves by now with my apparent obsession to remove TObjectlist :-) Even so, I will not give up. That damn class is wort fighting against ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What exactly is the discerning aspect of a leaf. It seems that not having a child is not enough. Is there set of token types (or something else) that makes a leaf.
You automatically assume any source token to be a leaf. Is that enough?
IOW, Does that mean any node that has a token type other than ttNone is a leaf?
I am trying to fold TSourceToken back to TParseTreeNode, that is why I need to know.
In general computer-science terms, a leaf node is any node with no children.
In this particular parse tree, all leaf nodes, and only leaf nodes, are source tokens. Non-leaf nodes represent groupings of source tokens, e.g. "expression", "case statement", "procedure", or "implementation section". See ParseTreeNodeType for the list of these types.
In the registry settings, select the "always show parse tree" radio, and you'll see the parse tree data displayed on a tree view.
From what I gather, TParseTreeNode and TSourceToken are basically the same thing (with TSourceTokenList thrown in to confuse the outsiders).
TSourceToken.NextToken is the same as TParseTreeNode.NextLeaf; same goes for TSourceToken.PriorToken().
These are basically functions calling functions and doing nothing other than wasting time in the process.
IOW, all are nodes, some are slightly different from others.
I would fold the two class into one. For simplicity and clarity.
I have not seen the latest CVS yet, this is based on the impressions before that:
TParseTreeNode.VisitTree() is an unnecessarily convoluted way of doing things. TXXVisitor already has a reference to the node in question. Why cant TXXVisitor directly do whatever is being done by this TParseTreeNode.VisitTree() ? It sure can. ANd, it is a lit more sensible, IMHO.
And then you would not need TVisitResult baggage of anomaly carried around all the time.
BTW, why were the elements of TVisitResult not properties of TXXVisitor I'll never know. But, anyway, that too is not important once TXXVisitor directly manipulates the Nodes.
Well, the code that I checked in yesterday, and which is 10% faster, does away with the interface on the visitor, and with TParseTreeNode.VisitTree.
That code is now in a singleton class, TTreeWalker, which knows about both parse trees and visitors (technically they aren't the visitor pattern anymore).
This code could move into TBaseTreeNodeVisitor, but I haven't decided if that would be an advantage yet.
TRVisitResult works as before, since the visitor classes haven't changed. Much.
Some information has to come back from the visit. The bare minimum here is a Boolean to tell if the items at or before the current have been disturbed. There is a loop through the parent node's children, done now in TTreeWalker.VisitTree:
liLoop := 0;
while liLoop < pcNode.ChildNodeCount do
begin
lcChildNode := pcNode.ChildNodes[liLoop];
// lcChildNode is visited...
The problem is that when the child node is a source token that is deleted or has token inserted before it, liLoop is not valid any more. We don't want to check it every time, for speed reasons, so need to know when it has changed.
I have managed to do away with the aInsertAfter action by adding
procedure TParseTreeNode.AddSiblingAfter(const pcChild: TParseTreeNode);
begin
Assert(Parent <> nil);
Assert(pcChild <> nil);
Parent.InsertChild(IndexOfSelf + 1, pcChild);
end;
> Parent.InsertChild(IndexOfSelf + 1, pcChild);
OMG, just look at this..
What you are doing is this:
IndexOfSelf: An expensive operation. It searches for itself in the parent list to find out its own index. ANd, this is an indirect call too --i.e. more than one function call. You dont use IndexOf() in an engine. It is reserved for GUI usage :-)
InsertChild(): Another expensive call. Internally, it searches for that index. Moves all the other items one cell further. Inserts the item...
Why all this?.. Just because we are stuck with TObjectList crap..
I must be getting on your nerves by now with my apparent obsession to remove TObjectlist :-) Even so, I will not give up. That damn class is wort fighting against ;-)