Re: desired features for gp backend?

[John W. Eaton]

On 17-Jun-2009, Jaroslav Hajek wrote:

| Here's an idea: what about bringing the gplot interface back in the
| form of an extension package?
| (Not that I like it, I've never used it)

I don't think you would be able to parse the expressions exactly the
way it was done in the past without changes to the parser.  Also, the
gplot function name is already taken for another purpose.

You could write a .m file that can accept some of the syntax.  For
example, try this:

  function Gplot (varargin)
    varargin
  end

  Gplot [-5:] [-1.2:1.2] var u 1:2 w l lw 3
  varargin =

  {
    [1,1] = [-5:]
    [1,2] = [-1.2:1.2]
    [1,3] = var
    [1,4] = u
    [1,5] = 1:2
    [1,6] = w
    [1,7] = l
    [1,8] = lw
    [1,9] = 3
  }

You can then parse the arguments so you can figure out whether VAR is a
variable or a data file (that could be ambiguous).  If you decide it
is variable you could get its value with "evalin ('calller', 'var')",
etc.  You might also want to handle variables in the using clauses, or the
linewith part or other places, like all the various set commands that
are possible.  I think it quickly becomes complicated.  Have fun
implementing nearly all of the gnuplot syntax in Octave...

But after all that work, you still won't be able to handle

  Gplot [-5:] [-1.2:1.2] var u 1:2 w l lw 3, var u 1:3 w p

because Octave's parser interprets the comma here as a command
separator (I think that is required for Matlab compatibility).

To avoid that, you need to be able to tell the parser that a function
like "Gplot" is special, and should somehow bypass the normal rules
and get all arguments up to the end of a line (maybe also handling
line continuations of some kind that are specific to the special
language that you are trying to parse).  The old "mark_as_raw_command"
attempted something like that, but it complicated the parser for very
little benefit, so I don't want to bring it back.

jwe