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

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

On Mon, 19 Jul 2004, Ethan Merritt wrote:

> > In short, all 98 calls of isstring(), and all 19
> > calls of m_quote_capture and all 62 of quote_str()
> 
> No.  You are misunderstanding, or I am totally failing to describe
> things properly.  

A combination of both, it appears.  I had lost overview somewhere along
the line of this, and you didn't see it happen.

> Patchset 1:
> -----------------
> 
> This patchset does 3 things.
[...]

> (3) It adds a check for this string-valued function in exactly two
> places where a function name was not previously accepted by
> the parser. 

I think what I'm getting at that this check had better go into isstring()
instead --- the function that every command parser fragment is supposed to
be using to check whether the upcoming command line token is a string or
not.

> Patchset 2
> ---------------
> 
> Adds a string-function evaluator. I don't know what the right term is
> for this, but basically it just triggers the existing function
> evaluation code. It is directly modelled on do_line(), except that it
> requires the top level function being evaluated to return a string.
> 
> At a single call site in write_multiline(), it checks for a magic
> leading sequence of characters in every string that is printed. If the
> sequence is recognized, it filters the string through the
> string-function evaluator.

Ah, thanks, now this is a whole lot clearer than before.  So this patch is
what I've been referring to as late evaluation, i.e. the technique of
storing an expression, rather than its result, to be evaluated at the
latest possible time.  I'm still not confinced that 'sprintf( is a
suitable choice of trigger string, but now at least I understand what
you're doing.

I.e. we're actually in perfect agreement as to what the necessary
features are --- we just used so completely different terms that we
confused each other completely.  Thanks for staying with me long enough
that we could finally sort this out.

> Possible next steps (hypothetical patchset 3)
> -------------------------------------------------------
> 
> Indeed there are other places that the current syntax does not
> allow a function name including, as you point out, the specification
> of file names.  This could be addressed in several ways.
> 
> (1) We can expand the legal syntax at these places one by
> one as they are needed or requested.

That might be an endless journey.  Better do it in a more brutal fashion:
either by documenting and recommending the ''+ trick to signal a string
expression coming up, or by changing isstring() and friends, as I
suggested earlier.

> (2) We could replace fopen() with an newly-defined gp_fopen() and
> add the string evaluation code only in the new routine.

> No comment on the DOS/Windows issue, but from my unix-centric
> perspective this is not at all what the single-quote convention is 
> expected to do.   Following the conventions of both sh- and csh-
> derived shells,  enclosing a character string inside single quotes
> should mean that absolutely nothing at all is done to it. 

And so far, before your second patchset, nothing is --- that patchset
actually breaks that rule.  Single quoted string are used as-is,
unmodified.  Except that when they're written out to save files, which may
not even stay on the same platform as the gnuplot executable they were
built on, it's unreliable to store them as single-quoted ones.  That's
where conv_text() comes in and generates an ASCII-only, portable
representation for us. The actual problem here was simply a bug in
conv_text().

This save file issue is one which we can get no guidance from Unix shells
from --- they don't save states of internal settings to files meant to be
read back in.

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