Re: user-defined function & string file name

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

On Wednesday 29 June 2005 05:10 am, Hans-Bernhard Br=F6ker wrote:
> Juergen Wieferink wrote:
>=20
>  > Such a function must not be called if the next token can be a key word=
=2E=20
>  > An invalid expression would lead to an int_error().=20
>=20
> This, however, seems deeply wrong.  A simple parsing helper function has=
=20
> no business bailing out to the command line.

This is a false concern.  int_error() will not happen, because it is=20
trivial to check whether the next token is a user-defined function or not.
The missing part is to how to check the return type of that udf.

Consider that the following is a legal function definition:

	f(plot,x) =3D  (plot =3D=3D 0) ? sin(x) : sprintf("datafile.%d",plot) =20

So `plot f(0,x), f(1,x)` should be equivalent to
   plot sin(x), "datafile.1"

The only alternative I see to trial evaluation is to add an infrastructure
for type-checking and type-propagation to the temp_at() code, and use it=20
to reject any function definition that propagates both string and non-string
types to the top of the evaluation tree.=20

I hasten to point out that so far as I know, the only place this is a real
issue is for the arguments to the `plot`, `splot`, and `fit` commands.
In all other cases it is safe to call try_to_get_string(), and then test
whether a string was actually returned or not.  At worst you end up
evaluating a non-string expression twice, once to find out it's not a=20
string and a second time to store the numerical result instead.  If this
is seen as a serious inefficiency, then at critical call sites the
code in try_to_get_string could be replicated in-line, keeping the
returned value for immediate use in either the string or non-string case.


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