There's no reason to parse and re-parse values from the input sequence over and over as we rewind in the secondary parser. Instead, I suggest that the underlying sequence should be read-only, and only read from when we attempt to .GetNext() past the end of the currently cached values.
This is a memory concern for large inputs. We could maybe offer the option to use the current "streaming" implementation or to use a cached implementation (trade more memory for better runtime performance) etc.
We cannot mix approaches, however. Because if we cache values in the ParseResultSequence, the SequenceCheckpoint cannot have enough space for both the underlying sequence to restore state AND the ParseResultSequence to move back to a previous cached position. So we're either caching everything as we go, or we're not caching anything and relying on the underlying sequence to handle state.
There's no reason to parse and re-parse values from the input sequence over and over as we rewind in the secondary parser. Instead, I suggest that the underlying sequence should be read-only, and only read from when we attempt to
.GetNext()past the end of the currently cached values.This is a memory concern for large inputs. We could maybe offer the option to use the current "streaming" implementation or to use a cached implementation (trade more memory for better runtime performance) etc.
We cannot mix approaches, however. Because if we cache values in the ParseResultSequence, the SequenceCheckpoint cannot have enough space for both the underlying sequence to restore state AND the ParseResultSequence to move back to a previous cached position. So we're either caching everything as we go, or we're not caching anything and relying on the underlying sequence to handle state.