gnuplot syntax (was: historysize)

[Juergen W. <wie...@fr...>]

On Tuesday 16 August 2005 17:57 Robert Hart wrote:
> [...], I think the problem is more a case of
> how clearly we define the syntax.
>
> Option 1. Variables take precedence over keywords.
> This would seem to make sense for the "backward compatibility" point of
> view you discuss above. Once a variable with the same name has been
> defined, it is used in preference.
>
> Option 2. Keywords take precedence over variables.
>
> Option 3. Precedence is irrelevant because:
>
> Option 3a. All keywords are reserved.
> Attempts to assign to a keyword variable would fail. This would break
> existing scripts in some cases, but make it very obvious how to fix
> them. Would require the parser to have a definite list of keywords,
> which is a long way off how it works at present.
>
> Option 3b. Variables made syntactically obvious (e.g. $x instead of x
> (like perl or bash).

Nice overview.  You might want to have a look at 

  RFE #1249742 "[syntax] optional expressions".

It's my trial to implement Option 2.  It turns out to be quite a lot
of work.  Option 1 could probably be implemented by little hacks
into equals() and almost_equals().  Option 3a is simply impossible
because of all the short cuts which form valid key words.  Consider

gnuplot> p "file" u 1:2 w l

And option 3b (as option 1) would break backward compatibility at
least once.  If such a step would be done, I'd strongly suggest to
think about a complete redesign of the syntax and the parser.

I don't feel comfortable with gnuplot syntax.  A simple example:
What does an empty "set" statement do?  Consider e.g. "set output",
"set pm3d" and "set label".


Juergen