Re: String variables

[Dave D. <dde...@es...>]

Petr Mikulik <mi...@ph...> writes:

>> >     set label 1 sprintf( "After fitting, A = %3.2f, B = %3.2f", A, B)
>>
>> That one, mostly.  Generally, the "A = $A" syntax may seem simple, but
>> it's also of rather limited flexibility.
>>
>> This function-like syntax also extends more naturally to other operations
>> on strings (scanning a string, reading a string from an external file,
>> ...).  I think we can take a hint from Java, here: Strings are native
>> datatypes, but the only operator they support is '+' for concatenation.
>> Everything else is done by functions.
>
> I would also prefer this way of sprintf and '+' operator for strings.
>

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 ?


Should both be supported ?

Eg  the plot ... using (expression)  broke backwards compatibility
because previously, 'using' expected a constant expression which gave
a column number.

As I'm sure you'll all remember, the brackets were a compromise. But
it's a bit ugly. There's nothing to say that the constant expression
could not contain brackets.


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.


(I'm not suggesting this as a way forward - just hightlighting the
issue)


I wonder if the parser is going to need help for identifying string
expressions. gnuplot has always had a fairly lax syntax, with optional
bits of commands being detected automatically.

Eg

f(x,y)=sprintf( "After fitting, A = %3.2f, B = %3.2f", x,y)

set label 1 f(A,B)


Could so something like

 set label 1 """f(A,B)"""

which alerts the lexer that there's a string expression next.

Or I think tcl uses [...] to indicate an expression.


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com