Re: [ gnuplot-Patches-992149 ] String variables revisited

[Hans-Bernhard B. <br...@ph...>]

On Mon, 19 Jul 2004, Ethan Merritt wrote:

> On Monday 19 July 2004 01:35 am, you wrote:
> > On Sun, 18 Jul 2004, Ethan A Merritt wrote:
> > > Anything you do _outside_ the quotes means that every single place
> > > that tests for a string constant has to be re-written to handle the
> > > possible substitution of other syntactic entities instead.
> >
> > And everything you do inside them means you have to handle the
> > substitution at every single point of the code that actually uses a
> > string.  That's not necessarily a much smaller set of places.  It could
> > actually be a good deal larger.
> 
> Have you actually tried the patchset?

Not really.  I've relied on your descriptions of it for now.

> Adding the test+evaluation in one place only, the text-printing
> routine write_multiline(), already catches a large majority of 
> useful cases.  Adding it to the file-open code (not sure exactly
> how many places that is) would catch most of the rest.

Catching most isn't the issue.  Catching all of them is.

> I may be missing some major class of possible uses for strings,
> but it seems to me that about covers it right there.  What else did
> you have in mind?

Every usage of strings anywhere in gnuplot.  Datafile names, output file
names, 'print' strings, plot elements (axis labels, tick labels, labels,
title, key title, key entries), fit 'update' and 'via' files,
save/load/call file names, 'cd' names, loadpath names, terminal-wide or
label-wise font names. In short, all 98 calls of isstring(), and all 19
calls of m_quote_capture and all 62 of quote_str()

> > It could almost certainly all be handled by extending m_quote_capture
> > to proceed evaluating a string-valued expression.
> 
> That is the second stage, yes, but the first stage is teaching all the
> parsing routines to accept something other than a quoted string in
> all the places they currently expect it.

Not really.  The trick I have in mind is to teach m_quote_capture()  and
friends themselves to accept a quoted string followed by whatever else
there is to the string-valued expression it started off.  Just as we
currently parse the function to be plotted by having the parser eat up
as much of the command line as fits the syntax of an expression, a 
string would continue until the next piece of syntax doesn't match the 
syntax of a string expression any longer.  

> > > Assume for the moment we use % for this purpose. Then the
> > > documentation would read:
> > > 	"<expression>"	evaluate immediately, with substitution
> > > 	'<expression>'		evaluate immediately, no substitution
> > > 	%<expression>%	evaluate later, with substitution at that time
> >
> > I honestly don't see why we need the middle variant.  What is the
> > difference between evaluation and substitution that makes you want
> > control over each of them independently?
> 
> ???
> That's what we have *now*.   You want to remove it?

No.  But you had me confused over what your terminology means there.

Now, looking at all this a bit closer, it seems like you're understanding
"substitution" to mean the stuff we already have for the first two cases
(\n, \0123, `backquotes`, ...), and "evaluation" for the new string stuff.  

Well, so far in gnuplot, late evaluation has been limited to the
definition of user-defined functions --- all other expressions are
evaluated to fixed results before the command they appear in is finished
executing.  That method has served us well so far, and before we stray
from that path, we should have a solid reason for doing so.

I honestly don't see the need for late evaluation from the user interface
side of things. I don't see a compelling reason why

	set title {some expression involving variable i}
	i = 5
	plot something
	i = 6
	plot something else

has to produce two different title strings, without even offering the
option of getting the same title on both of them.  Even closer to the
point, why should

	x = 6
	set label 'sprintf("%g", x)' at x, f(x)
	x = 1

show the label at position (6, f(6)), but print the string as '1.0'?
From where I sit, that makes no sense whatsoever.

So here's a new summary of the matter: late evaluation should be a 
subject kept separate from that of string variables.  If we add
late evaluation, it should be added it for both strings and numbers.

> [aside:  About the only thing I use the existing single-quote mode for
> is to allow inclusion of double-quotes in the string without having to
> escape them with backslashes.  But I don't think that was the original
> intent. What else is it useful for?]

E.g. for input of strings in terminals like LaTeX or PostScript enhanced,
where you really don't want to have to type every \ character twice, and
for DOS/Windows filenames, where \n processing would produce rather
surprising results.  Although the latter can be circumvented by using / to
separate directories, which works just as well, but most Windowsers don't
know that.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.