#481 Request builtin 'isstring' function

[Mike Tegtmeyer]

It is often advantagous to break out common functionality into callable scripts to promote code reuse for many applications. In these callable scripts, I find it advantagous to query the type of a variable to make decisions on how it should be used. A builtin isstring function would be most useful in these contexts.

A partial workaround can be accomplished using existing functionality. Given:

num=42
numstr="42"
var=num
varstr_num="num"
varstr_numstr="numstr"
varstr_non="blah"

A isstring function with the truth table:

 1. isstring(42) ->               false
 2. isstring("42") ->             TRUE
 3. isstring("blah") ->           TRUE
 4. isstring("num") ->            TRUE
 5. isstring("numstr") ->         TRUE
 6. isstring("varstr_num") ->     TRUE
 7. isstring("varstr_numstr") ->  TRUE 
 8. isstring("varstr_non") ->     TRUE
 9. isstring(num) ->              false
10. isstring(numstr) ->           TRUE
11. isstring(varstr_num) ->       TRUE
12. isstring(varstr_numstr) ->    TRUE
13. isstring(varstr_non) ->       TRUE

Can be implemented by:

isstring(x)=(exists(x)?1:(sprintf("%f",value(x)) eq sprintf("%f",NaN)))

This does not determine if the value of a string variable is a non-string. That is, isstring returns (2) and (10) as strings (they are) but they would also participate in auto-promotion to a number.

    G N U P L O T
    Version 5.2 patchlevel 4    last modified 2018-06-01 

    Copyright (C) 1986-1993, 1998, 2004, 2007-2018
    Thomas Williams, Colin Kelley and many others

    gnuplot home:     http://www.gnuplot.info
    faq, bugs, etc:   type "help FAQ"
    immediate help:   type "help"  (plot window: hit 'h')

Via MacPorts

[Ethan Merritt]

That's a little bit problematic in the context of a language that does duck typing.

gnuplot> THREE = "3"
gnuplot> print THREE + 42
45
gnuplot> print THREE
3
gnuplot> print THREE[1:1]
3

You propose that isstring(THREE) would report TRUE, but if the purpose of the test is to determine whether arithmetic operations are possible that test misses the point. They are possible because THREE also acts as an integer. If we were to introduce such a built-in at the command level, wouldn't there also need to be a corresponding isnumber(), isarray(), and so on?

The current source has an internal function type_udv(token) that returns a DATA_TYPES enum (INTGR, CMPLX, ARRAY, NOTDEFINED,...). That would be a more complete test, but my first reaction is that exposing such internal details at the user level would be a bad idea.

[Mike Tegtmeyer]

Agreed it is problematic;

This does not determine if the value of a string variable is a non-string. That is, isstring returns (2) and (10) as strings (they are) but they would also participate in auto-promotion to a number.

To me, the need is partially due to the duck typing. In each of the examples you provided, the string "3" auto-promoted to a number as needed to complet the expression. This doesn't seem universal however which means that workarounds need to be created in places where it doesn't.

For example:

gnuplot> print(sprintf("%f","3"))
         f_sprintf: attempt to print string value with numeric format
gnuplot> print(value("3"))
NaN

Another use case is related to #2073 in that the call command always passes it's arguments as strings. For example, suppose a called (otherwise complex) script expects a numeric argument that includes printing a label. If it is a integer, format it with sprintf("%i"), if it a real, with sprintf("%.2f"). Sure this could be formatted externally but if the script is intended to be reused... (and this is a bit of a contrived example). If the parameter is always a string, then some level of introspection needs to be done to determine which it should choose. Additionally, suppose several call sites deep, the script was called with a non-number argument due to programmer error or input data (may generated by some other application). To me, it is easier to debug if something checked the input argument and provided a reasonable error message rather than failing somewhere deep within the script.

I could see exposing the type_udv function (or some sanitized version thereof) opening up a lot of possibilities especially in the case of arrays. I'll also argue that many dynamically-typed languages have some level of introspection capability. I'm not familair with the source so short of pulling it down and grepping for the definition, there could be DATA_TYPES enumerations that could really confuse things/users.

[Ethan Merritt]

From a developer perspective, there is a sharp line between operations that are handled by treating them as C language features and operations that are implemented by gnuplot internal code which happens to be written in C but could just as well be in some other language. I realize that this line may be considerably blurrier to users.

The call to "sprintf" is a very thin wrapper around the corresponding standard C library routine. The C library does not do duck typing. Gnuplot separately provides its own formatting routine "gprintf" which is implemented internally and thus does do auto-promotion. The documentation (help sprintf) explicitly mentions the distinction between formatting via the C library call and via gnuplot formatting.

 gnuplot> THREE = "3"
 gnuplot> print gprintf("%.2f", THREE)
3.00

I have not yet looked at your "call" examples in the bug report.

[Mike Tegtmeyer]

I was just using sprintf as an example where results were different depending on the underlying type of the its argument--including potentially generating a syntax error.