Re: String variables

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

On Tue, 13 Jul 2004, Dave Denholm wrote:

> There is another question : should that evaluate the expression
> (sprintf...) once and store the resulting string value in the label,
> or should it store the expression and re-evaluate it for every plot ?

Depends on where the expression appears, I should think.  If we only
provide string variables, but not string-valued expression available
everwhere, this question won't arise.  

Generally, it should work like it does with numeric expressions vs.  
user-defined variables now:

	myfunx(x)=x**2
	a = myfunc(2)
	myfunc(x)=x**3
	plot a, myfunc(x)

will plot a constant 2 (not 8), and x**3.  I.e. all expression remain
to be evaluated when the command they appear in is executed.

> Here the analogy would be that
> 
>   set label 1 sprintf( "After fitting, A = %3.2f, B = %3.2f", A, B)
> 
> evaluates it once and stores the result, but
> 
>   set label 1 (sprintf( "After fitting, A = %3.2f, B = %3.2f", A, B))
> 
> stores it as an expression.

We'll need a different syntax, but the feature itself would probably be a
good idea.  And not only for strings, either.  Something like '$()' to
signify 'late expansion' (i.e. only when the value is actually needed),
maybe.

> I wonder if the parser is going to need help for identifying string
> expressions.

Quite definitely it will.  Technically, we'll need to extend
the is_string() function in some tricky way.  So far, my vague idea
was to require string-valued expressions to always start with a
string constant, for its benefit.  I.e. we would have
	
	plot f(x)   # numeric expr. --> function
	plot 'file' # string --> file name
	plot ''+g(p,q)  # string --> computed filename

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