removing gnuplot from the parser and lexer

[Teemu Ikonen]

Hi all,

A substantial part of the Octave parser and lexer is devoted to handling the
gnuplot-compatible plotting commands gplot, gsplot and gset. Having plotting
commands as reserved words on a programming language, as Octave has, has
always seemed a bit weird to me, so I wanted to see if I could remove those
in a compatible way by just doing some pattern matching and simple
heuristics on a gplot function call and feeding the parts containing octave
expressions to eval_string(). It turns out that this is possible at the cost
of very little loss in backward compatibility, and some small changes to
core Octave.

To get to the gplot commandline in Octave I had to make some small changes
to the lexer and introduce a new type of command-style functions that
receives its input as unevaluated strings. Only the comment and continuation
characters are treated as in other commands. The attached patches introduce
commands mark_as_rawcommand, unmark_rawcommand and israwcommand, which set,
unset and check this property in a symbol (or more precisely, in any
string).

When my gplot replacement function (gpt_plot, attached) receives a command
string, it lexes it with it's own lexer and does some simple parsing to
determine the expressions needed in range, plot and plot parameter part of
the plotting command and evaluates them. The assembled plot command is then
fed to gnuplot. This is possible without needing to have a full Octave
parser in the plotting function because the Octave expressions in the gplot
command are (almost) always separated by special plot tokens or range
separators ([,:,]).

I've tested my new functions with the stock M-lab compatible plotting
commands from the scripts/plot directory, and they work identically to the
old ones at least on the simpler invocations of these commands.

There are two exceptions to the simple, token separated plotting grammar (in
src/parse.y) which are not supported by my functions. The first is the pair
of rules

using   : using1
          | using1 expression   
using1  : USING expression
          | using1 COLON expression
          
which can lead to accepted sequences such as 

USING expr : expr expr

where two expressions are separated by whitespace. Fortunately, the current
Octave parser doesn't use the latter expression for anything, so this can be
handled in a way that is nearly compatible with the old syntax.

The other exception is the rule

style   : WITH STYLE
          | WITH STYLE expression
          | WITH STYLE expression expression

in which the last rule again contains two whitespace separated expressions.
The current plotting m-files call gplot through sprintf generated strings
where the line and point widths are passed as constants, which my functions
can handle, so even this is not a big problem. If compatibility is really
needed here, the parser could perhaps be tweaked in a non-gnuplot specific
way to handle whitespace-separated expression lists in eval_string().

The attached patches and functions still need some polishing and testing,
but I'd like to know if this kind of change would be welcome before working
more on them. 

Teemu

rawpatch.tgz
Description: application/tar-gz

gpt.tgz
Description: application/tar-gz