#2547 Negative numeric value for 'call' command's argument

[Hiroki Motoyoshi]

It seems that if I give a negative number directly to the 'call' command, the negative sign and the numeric part are passed as separate arguments.

File: sub.gp

print ARGV

File: main.gp

call "sub.gp" 100
call "sub.gp" -100
call "sub.gp" (-100)

call "sub.gp" +100
call "sub.gp" (+100)

% gnuplot main.gp
[100.0]
["-",100.0]
[-100]
["+",100.0]
[100]

[Ethan Merritt]

Indeed. This was true at least as far back as 1998 (version 3.7.1), and it was documented to be that way. The details of the calling convention have changed substantially since then but that behavior remains the same. Unfortunately the documentation no longer makes this point clear.

Given the project's strong emphasis on backward compatibility with old scripts, I don't think this is fixable.

I was working off and on to implement a function call mechanism that is more similar to other languages. It's in a private git branch, and in the current state it has serious problems so I more or less abandoned it. The goal was to facilitate mutli-line function definitions and add support for variable names that have scope local to the function definition. The concept is currently

Example of private variables in a function definition:
  F(a,b,x) = {
    private temp
    temp = complicated_function(x)
    a * temp**2 + b * temp
  }
The current value of temp (if any) is saved on entry to F
and restored on exit.  This means that the assignment statement
inside the function does not have globally visible side effects.

The code I have works if no error is encountered during execution, but gnuplot's use of longjump to reset the execution context after an error means that any global variables shadowed by a local variable name are trashed by error recovery.

See also https://sourceforge.net/p/gnuplot/feature-requests/521/

Any help, suggestions, or actual code contributions would be great.

[Hiroki Motoyoshi]

Thank you for the detailed explanation.

I confirmed that there was a description of the parameter delimiter in the document up to version 4.6.6.

The call command is identical to the load command with one exception: you can have up to ten additional parameters to the command (delimited according to the standard parser rules) which can be substituted into the lines read from the file.

I finally understood the precise behavior from this document, because in my script ‘call “sub.gp” 1+2+3’ generated the output ‘[1.0,”+”,2.0,”+”,3.0]’ for example. Even so, the "standard parser rules" may be difficult to understand for users who are not interested in how gnuplot parsing works.

How about introducing a "set" option to change the behavior of the "call" argument's delimiter in order to achieve both "backward compatibility" and "usability"?

For example,

set call delimiter {whitespace | classic}

[Ethan Merritt]

I don't think that the separator character is relevant here. Gnuplot's input stage separates the input line into "tokens" without regard to separators or whitespace. So far as gnuplot is concerned, there is no difference between -3+B and - 3 + B. It does not store the intervening separator characters, only a list of tokens. Both of the above input strings result in four tokens - 3 + B.

Given the current code organization, the only choice available when constructing a list of parameters to be passed is whether to evaluate the tokens individual or in aggregate or not at all. I.e. should B be passed as a string, or should should it be substituted by the current value of a variable named "B"? What if there is no variable named "B"? Should tokens - and 3 be evaluated as -3? And if so, then how should it know to stop evaluation at that point and not continue so that the entire string is reduced to the current numeric value of B-3?

IMHO the idea for a call mechanism was poorly thought out at the outset 20+ years ago, and the subsequent introduction of support for non-numeric variables and text blocks only made the inadequate design more obvious. I would prefer to leave it as it is for backward compatibility while considering ways to introduce a better defined and more powerful mechanism for supporting the equivalent of subroutines and scoped variables.

[Hiroki Motoyoshi]

So far as gnuplot is concerned, there is no difference between -3+B and - 3 + B.

As you said, it is true that whitespace does not work as a delimeter. I opened this ticket because I was surprised that "-100" was interpreted as "-" "100". However, I learned from this exchange that it is safe to enclose the parameter in parentheses when passing value expected as numbers.

I would prefer to leave it as it is for backward compatibility while considering ways to introduce a better defined and more powerful mechanism for supporting the equivalent of subroutines and scoped variables.

I agree with this and hope that such an implementation will be made :-)