If you're extending the numeric formats, a great one would be to expand
octave_read_value<Complex> to accept non-real numbers. I'm currently
working on a C++ implementation of textscan based on John's skeleton of a
couple of years ago. It is mostly done, but it won't be able to replace the
.m version until it can read complex numbers.
More generally, there are a few features that seem to need lookahead:
1. Reading complex numbers (1+2.3e-09i is complex, but 1+2.3e-09 is two
2. multi-character comments symbols (like //), multi-character delimiters
and multi-character TreatAsEmpty symbols.
The way the second group are handled will depend on how the complex numbers
are handled. I was thinking of writing a streambuf that provides multiple
characters of 'putback', but wasn't sure if that is appropriate. (For
textscan, the alternative is to read an entire line into memory at once, but
that could be huge, since it allows \n to be ignored.) If you can think of
how to read complex numbers, I'll see if that approach applies to the others
What you say is probably true. However, at the moment I'm focused
on the parser--the routines that process what you type on the
command line. octave_read_value() seems to be a part of stream
processing, and entirely different code base, and is invoked when
you process a file through the 'load' command.