Re: historysize

[Robert H. <en...@no...>]

On Tue, 2005-08-16 at 16:31 +0200, Hans-Bernhard Broeker wrote:
> Daniel J Sebald wrote:
> > like when negative numbers have special meaning.  The data file "using" 
> > format is like this; 0 means point, -1 means line number, -2 means index 
> > number.  I find that not user friendly.  How do others feel?
> 
> While it may appear more user-friendly to use names instead of numbers, 
> at least in the case of existing syntax, that's a risky change to make.
> 
> > I'd suggest "unlimited", "infinity", "infinite" rather than -1.
> 
> Now imagine somebody who just happens to have an old gnuplot script
> that defines all of the above variables equals to 5.  Or to 1/0, for 
> that matter, or 1.0e300.

Well, ignoring for a second the shear unlikelihood of somebody loading
an old gnuplot script that used a variable name at a position that would
be ambiguous in the new version, 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).


One thing I'd like to see is better support for using plot variables in
other places of the plot command. e.g. I was trying to do something like
this:
splot "data.txt" lc rgb(x,y,z)
or
splot "data.txt" using 1:2:3:rgb($1,$2,$3) lc variable

The current syntax seems to support whatever the needs were of the
person who wrote each plot type.

In general however, I'm against the introduction of new "language
features" into gnuplot. I think in many cases the better approach is to
generate gnuplot scripts programmatically.

Rob

-- 
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.