Re: Request for comments: string variable patchset 2

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

On Friday 15 October 2004 12:01 am, Petr Mikulik wrote:
> I would propose to ignore macro expansion in `blabla1` and
> !blabla2
> 
> but allow them in
> system('blabla2')
> and in
> value = execute('blabla1');
> 
> Where the execute() is a new command. The user could use what he wants.

I think that would be possible.
The string expansion routine would be called in two places.
When called to process the entire command line it would not expand inside
back-tics.  When called to expand the argument to a particular function, in
this case system() or execute(), then it *would* expand in backtics.

Anyone else have an opinion on that point?

Another alternative is to provide a run-time option
	set macro$expansion {none|all|nobacktics}


> >>   gnuplot> print sprintf("%i", 5.)
> >>   0
> >This example doesn't work in C either.
> 
> But it works in Octave and awk; I use it there to print an integer part of
> the value. I would rather prefer an inteligent version that returns in the
> above example 5.

If Octave does that, I'd say it's a bug, or at least an unreliable behaviour.
Auto-conversion of an ambiguous variable type is one thing, but
refusing to do what the user asks for is quite another.
You have explicitly given a floating point number, and explicitly
given an integer format.  That is user error.  Is it "intelligent"
for a program to over-ride what the user has explicitly asked for?

> > FOO = floor(FOO)
> > "see man page for sprintf"
> 
> Well, "man floor" says that result of floor() and ceil() is also a double
> value, so it does not help. Just in gnuplot it returns an integer.

I was not justifying gnuplot's use of floor; I was just responding
to the request for a way to insure that a gnuplot variable was an
integer.  That command happens to work already.
I have no objection to adding a built-in function  int(x).

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195