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

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

[Another long post. Please read it in the hope that all will
become clear.  Or at least become clearer than it is at
present.]

Let me start with a plea to drop the term "late evaluation",
which I think is side-tracking the current discussion.
Whatever it may mean to different people, I don't think it is
a useful way of thinking about my patchsets.

The evaluation of expressions containing string functions is no
different from the evaluation of all other gnuplot functions.
The evaluation is never "late"; it happens when it happens.

Consider the existing case with no strings:

# user function is defined
   f(x) = sin(x)    
# user function is evaluated and result goes in var1
   var1 = f(3.0)
# user function is stored with plot for use in plotting,
# evaluation happens at plot time
   plot 'data' using 1:(f($2))

In the first two cases the function is evaluated at the
time the command line is parsed.
In the third case the function is evaluated once per data
point, but not until the file is read in during plotting.
This is obvious, I hope.

So....
What I did was expand the variety of functions to include
string-valued functions.  But otherwise the evaluation works
the same way

# (1) User function is defined
   f(x) = sprintf("%7.5f",x)
# (2) Pre-defined function is evaluated and result stored
   var1 = sprintf("%2.1f",x)
# (3) Same thing using user function instead
   var2 = f(x)
# (4) User function is stored with plot for use in plotting
   plot 'data' using 1:2:(f($2))

(1) Needs a bit more code to make it work, but is straightforward
(2) This is, I thought, what everyone was asking for but now we
seem to be arguing about
(3) Combination of (1) and (2); evaluation is done in two steps but
still at the time the command line is parsed.
(4) Evaluation of f(x), which is really sprintf("fmt",x) in this case,
does not happen until the data is read in.   In fact the command
I show here as an example is currently broken because of issues
with assumed column contents (see other thread).  But I was 
planning to fix this for the next version of the patchsets.

The point is that in each case, string or no string, the evaluation 
happens at the time it is needed. For 'set <foo>' commands 
this is usually at the time the command line is parsed, but for
'plot/splot/fit' commands it happens elsewhere.  

That inevitably leads to the question "how does gnuplot know that
evaluation is needed?", and that's where the fun (or argument) started.
In all the examples I gave above it is conceptually all the same
whether the variables and functions take on int- or real- values or
whether they take on string values.

But there are a few operations where the two possibilites diverge.
For example, real-valued variables are used (and changed) during
fitting.  I can't imagine that being a meaningful operation for a 
string variable.

Conversely, one thing we do with strings is to print them,
something that doesn't happen to numbers or at least only via
an intermediate string.  Printing a string constant is easy; we do
that already.  But how do you store, or mark, a string-valued
function so the gnuplot knows it must be evaluated and printed?
That is the heart of this discussion.   

I picked on up a suggestion from Hans to mark a string-valued
function by inserting some "magic characters" inside the quotes.
I thought that was a clever idea because it is transparent to the
existing code.  I am bemused by the controversy this seems to
have generated.  

There are two issues:  
how it looks on the command line, and how it is stored internally.

Look, I really don't care how we do it.  This seemed to me a clever
representation.  In addition to being compatible with the 
current code, it means that the internal representation is the
same as the command-line representation (quote + magic chars).
But these are mere conveniences, and are totally separate from
the core functionality.  Feel free to propose other represenations,
and explain why they are better.



And now, finally to Volker's specific questions....

On Wednesday 21 July 2004 12:33 am, Volker Dobler wrote:
> I think 98 sites which do memory allocation themself is more
> dangerous than replacing 98 call sites with one tested and
> correct call to m_quote_capture.

I have no comment at this time.
I will revisit your earlier patch and see what you did there.
Are you willing to help fix things if this mass substitution 
breaks them?

> Regarding the discussion about late evaluation:  I would like
> to _object_ to late evaluation.  Late evaluation will intruduce
> much more problems in user space than it will solve.

Petr said this too.  I am totally not understanding this 
concern.  But then again, I don't even know what you think
"late evaluation" means. 
Could you give an example?

> If I construct a string (regardless if done by the '' + trick or sprintf
> or anyting else) I expect it to be the way I constructed it;
> at least that's the behavior of all programming languages I am
> familiar with.

Yes.  That's fine.  That's what the sprintf() function does -
it constructs a string permanently and stores it in a variable.
That variable always contains the string you constructed.
It does not change.  Ever.

The point which is confusing is that string may in fact contain a
command.  But even this is not new - the hot-key bindings are
strings that contain commands. The command they contain is
executed "when needed", which in the case of key bindings
is in response to an event generated externally.
If you type 'bind' it will print a list of these stored commands.
It's the same with the string variables. 
If you type 'show VAR' it will show you what command is stored
there.  But there are other places in the code that can actually
execute that command when needed.

Users are under no obligation to store commands in string
variables any more than they are required to program new hot-key
bindings.  It's just something you *can* do if it proves useful.
  

-- 
Ethan A Merritt