Re: user-defined function & string file name

[Juergen W. <wie...@fr...>]

Hans-Bernhard Br=F6ker wrote:
> > Consider that the following is a legal function definition:
> >
> > f(plot,x) =3D  (plot =3D=3D 0) ? sin(x) : sprintf("datafile.%d",plot)
>
> I think it shouldn't be.  It's an invitation for utter confusion to
> reign in users' heads.  If it's any help: even C, in all its
> carelessness for types, forbids the two expressions surrounding the : of
> a ternay expression being of incompatible type.
>
> We really have to take a decision here:  either we have a typing system,
> or we go the Perl way, which would imply a need for type-punning
> functions or hacks like ''.<expressio> to work around unexpectedly wrong
> types.
>
> > 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 to reject any function definition that
> > propagates both string and non-string types to the top of the
> > evaluation tree.

This is especially the case for "f(x)=3Dx?a:b" or even "f(x)=3Dx" and
"f(x)=3Da".  As long as variables don't need to be declared, we are
stuck to the "perl way", I fear.

It may be possible to mimic execute_at() to obtain the resulting
type without actually executing the action table.  This is quite a
lot of work and not very elegant.

> Exactly my point.
>
> > At worst you end up evaluating a non-string expression twice, once to
> > find out it's not a string and a second time to store the numerical
> > result instead.
>
> And if that expression has side-effects (like the recently proposed
> system(<string>) or rand()), this is "at worst" can indeed be quite
> bad.
>
>  > 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.
>
> In-line expansion wouldn't be needed.  A simple ptr argument where
> try_to_get_string() can store the result of its attempted evaluation
> would be quite enough --- it may have to be renamed then, though, to
> evaluate_expression_of_as_yet_unknown_type() or something like that :-)

Am I right on this:

If the next token on the command line is either a key word [or any
other token with a special meaning like '('], or it is an
expression.  In the latter case, numerical and string values are
often treated in a different way.  But either way, the expression
has to be evaluated.  I am aware of the three exceptions "plot",
"splot" and "fit".  Well, and possibly a function definition.  :-)
And the cases where STRING_RESULT_ONLY is used, but in these cases,
a numerical value at that point is illegal.=20

I'd say, the conditional should generally be done after
const_express().  The expression is needed anyhow.  Only the three
dummyexpression/filename cases (s?plot|fit) need to be treated
slightly different.

This is possible without evaluating anything twice.  The major
drawback is that this doesn't work well with GP_STRING_VARS being
optional.  [Could STRINGs be allowed without GP_STRING_VARS for this
special case?]


Juergen