Re: user-defined function & string file name

[<br...@ph...>]

> Consider that the following is a legal function definition:
> 
> f(plot,x) =  (plot == 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.

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 :-)