Re: user-defined function & string file name

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

Juergen Wieferink wrote:

> A function isstringfunc() will have to evaluate the whole
> expression.

If so, that strongly suggests a serious design flaw to me.  The 
expression evaluation engine didn't have a type system before the 
introduction of string-variables, because it didn't need one.  Now we 
need one, but what you say there means we don't have it.  It must be 
possible to find out an expression's result type without computing its 
actual value.  If there's any ambiguity, force people to resolve it by 
using type-punning operators like real(), int() or string(), or 
equivalently by starting (sub-)expressions with ''. or 0+

> This should only be tried if we know that the syntax
> requires an expression.  Such a function must not be called if the
> next token can be a key word.

Then let's make sure we find all such cases early enough to change the 
syntax to require keywords wherever possible.

 > An invalid expression would lead to
> an int_error().

This, however, seems deeply wrong.  A simple parsing helper function has 
no business bailing out to the command line.  If it were 
"parse_expression()", i.e. it was supposed to do something with the 
expression, that might be a different thing, but a mere test meant to 
reveal what the next token actually is must not under any circumstances 
fail that badly.

> All call sites in the sources would have to be checked and quite few
> would have to be rewritten if they were to use isstringfunc().

All call sites have to be checked anyway.