Re: gnuplot-4.4.0-rc1 breaks gnuplot script

[Ethan M. <merritt@u.washington.edu>]

On Sunday 14 February 2010, Teo S Bernhard wrote:

>   c) In the briefer usage instruction (repeated below) I notice the
> optional trailing comma after definitions {,},  I also notice the
> replaceable <function>.
>   Considering the interpretation of item c), practical experience with
> gnuplot versions 4.3, 4.2, 4.0,...,  suggest that there is no need for
> a trailing comma after a  definition if there is no trailing
> <function>, here <function> can be replaced by nothing. In my opinion,
> the latter is a reasonable interpretation which is supported by
> historic gnuplot implementations. See the brief usage instruction:
>      plot {<ranges>}
>              {<iteration>}
>              {<function> | {"<datafile>" {datafile-modifiers}}}
>              {axes <axes>} {<title-spec>} {with <style>}
>              {, {definitions{,}} <function> ...}

You are not interpreting this BNF description correctly.
The meaning of the final line quoted immediately above is
  "If you append a comma you must follow it with a function.
   The function may optionally be preceded by a definition,
   with or without a separating comma."

The <function> element is not in curly brackets, and hence is
not optional.  There is no expansion of this set of BNF rules that 
results in a trailing definition.  So no, the documentation
has never stated that a trailing definition was valid syntax.
 
> My claim is therefore that previous gnuplot version, prior to gnuplot
> 4.4 rc1, behaved according to this documentation whereas version 4.4
> rc 1 does not behave according to the documentation regarding item c,
> this causes gnuplot 4.4 rc1 to break backwards compatibility.
> 
> If you agree, please consider the following patch vs. gnuplot 4.4 rc1
> for allowing trailing definitions in a plot command:  plot [-1:1] k=0,
> k*x, k=k+1, k*x, k=k+1
> As can be seen, only one code line needs to be modified - in two
> places. The modified if-statement is the one that causes an error
> message.
> With this modification, a trailing definition is silently accepted
> whereas earlier syntax errors are triggered as before.

I don't think it makes sense to do this without also doing one of 
the following:
 1) fix bug #2907028
 2) document that it is not permissible to use a definition of
    the form q = <expression involving q> inside a plot statment.
Otherwise it is nearly impossible to figure out how the program will
assign the instantaneous value of q is during the plot.