ITreeNodeStream Interface

Only makes sense for streams that buffer everything up probably, but might be useful to display the entire stream or for testing. This value includes a single EOF.

Return the current input symbol index 0..n where n indicates the last symbol has been read. The index is the symbol about to be read not the most recently read symbol.

Get a tree node at an absolute index i; 0..n-1. If you don't want to buffer up nodes, then this method makes no sense for you.

Where are you getting symbols from? Normally, implementations will pass the buck all the way to the lexer who can ask its input stream for the file name or whatever.

If the tree associated with this stream was created from a {@link TokenStream}, you can specify it here. Used to do rule {@code $text} attribute in tree parser. Optional unless you use tree parser rule {@code $text} attribute or {@code output=template} and {@code rewrite=true} options.

What adaptor can tell me how to interpret/navigate nodes and trees. E.g., get text of a node.

Where is this stream pulling nodes from? This is not the name, but the object that provides node objects.

As we flatten the tree, we use {@link Token#UP}, {@link Token#DOWN} nodes to represent the tree structure. When debugging we need unique nodes so we have to instantiate new ones. When doing normal tree parsing, it's slow and a waste of memory to create unique navigation nodes. Default should be {@code false}.

Get int at current input pointer + i ahead where i=1 is next int. Negative indexes are allowed. LA(-1) is previous token (token just matched). LA(-i) where i is before first token should yield -1, invalid char / EOF.

Get tree node at current input pointer + k ahead where k==1 is next node. k<0 indicates nodes in the past. So {@code LT(-1)} is previous node, but implementations are not required to provide results for k < -1. {@code LT(0)} is undefined. For k<=n, return . Return for {@code LT(0)} and any index that results in an absolute address that is negative.

Tell the stream to start buffering if it hasn't already. Return current input position, Index, or some other marker so that when passed to rewind() you get back to the same spot. rewind(mark()) should not affect the input cursor. The Lexer track line/col info as well as input index so its markers are not pure input indexes. Same for tree node streams.

You may want to commit to a backtrack but don't want to force the stream to keep bookkeeping objects around for a marker that is no longer necessary. This will have the same behavior as rewind() except it releases resources without the backward seek. This must throw away resources for all markers back to the marker argument. So if you're nested 5 levels of mark(), and then release(2) you have to release resources for depths 2..5.

Replace children of {@code parent} from index {@code startChildIndex} to {@code stopChildIndex} with {@code t}, which might be a list. Number of children may be different after this call. The stream is notified because it is walking the tree and might need to know you are monkeying with the underlying tree. Also, it might be able to modify the node stream to avoid restreaming for future phases.

Rewind to the input position of the last marker. Used currently only after a cyclic DFA and just before starting a sem/syn predicate to get the input position back to the start of the decision. Do not "pop" the marker off the state. mark(i) and rewind(i) should balance still. It is like invoking rewind(last marker) but it should not "pop" the marker off. It's like seek(last marker's input position).

Reset the stream so that next call to index would return marker. The marker will usually be Index but it doesn't have to be. It's just a marker to indicate what state the stream was in. This is essentially calling release() and seek(). If there are markers created after this marker argument, this routine must unroll them like a stack. Assume the state the stream was in when this marker was created.

Set the input cursor to the position indicated by index. This is normally used to seek ahead in the input stream. No buffering is required to do this unless you know your stream will use seek to move backwards such as when backtracking.

Return the text of all nodes from {@code start} to {@code stop}, inclusive. If the stream does not buffer all the nodes then it can still walk recursively from start until stop. You can always return {@code null} or {@code ""} too, but users should not access {@code $ruleLabel.text} in an action of course in that case.