Re: String variables

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

Ethan Merritt <merritt@u.washington.edu> writes:

> On Thursday 08 July 2004 03:27 am,  
> Hans-Bernhard Broeker <br...@ph...> wrote:
>>
>> > I also have some largish patches corresponding to implementations
>> > of several different flavors of user-accessible string variables.
>> > These have been discussed off and on over the last year or so,
>> > but I never sensed a real consensus as to which approach was
>> > best.
>>
>> I think that means we'll need a summary of their differences to
>> start off that discussion again.  As far as I remember, there
>> were several open issues we never decided upon conclusively:


>> 1) how deep down into the expression evaluator do we put them, i.e. do
>> we only need string-valued variables controlled by a 'set' or 'let'
>> command of their own, or should 'string' become a third native type of
>> expression, in addition to integer and complex, meaning that we could
>> have string operators, string arguments and results in both internal and
>> user-defined functions?


> But I don't really see how either of these would work on the
> command line. The existing "userstrings" patch allows
>
>     STYLE1 = "1:4 with lines lw 2"
>     plot 'datafile' using $STYLE1
>
> or even
>
>     Source1 = " 'data1' using 1:4"
>     Source2 = " 'data2' using 2:3"
>     plot $Source1 with lines, $Source2 with points
>
> How does printf/sprintf fit in here? 
>
> Admittedly the userstrings patch would probably better be
> described as implementing macro definitions rather string variables,
> but it raises the same issues of acceptable syntax.
>


I see this as the crux of the issue. As you say, userstring patch is
really macros rather than full string variables. I spent a bit of time
thinking about "true" string expressions / variables a long time
ago. That would be my preference, though since the chances are I won't
have any time to implement anything, I don't want to push my views too
hard.

If I did have time, then my goal would be able to do something like

 plot 'file' using (timecolumn("format, 1) + timecolumn("fmt", 3)):5

where (I hope it's obvious) timecolumn is a built-in function like
column() but which allows the format to be supplied as a parameter.
This fixes some of the problems with timefmt where only one format can
be specified, for example.

I would go as far as allowing user-defined functions which take and
return strings, etc. I had always assumed that STRING would become the
third type of a value.


String literals in expressions become a complication. (Assuming
expression evaluation is still as it was a few years ago.) My plan had
been to store a string table in an action table where the literals
go. This way, the literals last for as long as the action table lasts,
which may be brief for a temporary at, or for the duration of a plot
for a plot-using expression, or for the lifetime of a user-defined
function.


As is pointed out, this doesn't allow strings to be used as macros. My
suggestion was to provide an eval()-like command which evaluates
a string expression, then puts that back through the parser to
interpret it as a gnuplot command. Ugly, but...
And of course, a user-defined function could invoke eval() and really
make things complicated.



My only objection to the string-macros patch is that it would get
in the way of a "full" string-expression change later.


But anyway, it's a long time since I've been actively involved in
development, so I don't want to push my own opinions on this.



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