Open jMarcS opened 11 years ago
I'm currently looking at the commands that use arrays without indices (like a[]
), to see if the new helpers I put in with Issue #39 can simplify the code. This may come under the heading of "it ain't broke", but I figure it's worth a look.
In particular, it turns out the SELECT command is one of the cases that can call a UDF twice. The second parameter may be a numeric expression or a string array variable with no indices. The existing code was like PRINT in that it calls evalNumericExpression()
first, then checks for the special case of an array variable.
I found that I can reverse the cases. First call getVar()
. If the var is an array, and it has no indices, it can't be part of a numeric expression, so it is safe to assume the special case.
And there's a fringe benefit: by sticking a check for SyntaxError
after the getVar()
call, the "array must be dimed" run-time error shows up on the console only once, instead of three times.
Fn.Def changes released in v01.74. Issue still open.
Hi Marc,
In my opinion this is a serious problem. But an ad hock not smart solution is to parse the string function call: If you change PRINT GetBarCodeSimple$(globals) to myResult$ = GetBarCodeSimple$(globals) PRINT myResult$ you get the correct result.
/ Gregor
There are some commands, like PRINT, where a parameter can be either a string expression or a numeric expression. (TODO: get a list of all such commands.)
PRINT first calls
evalNumericExpression()
. If that fails, it backs up theLineIndex
and tries again, this time callingevalStringExpression()
.Most of the time, that works very well, but it introduces an ambiguity. When
evalNumericExpression()
returnsfalse
, it may mean there is no numeric expression or there is a syntax error (I suppose sometimes it means both).This has some interesting consequences.
evalNumericExpression()
must not callRunTimeError()
, directly or indirectly. It can setSyntaxError
-- and should: if all syntax errors it can catch are flagged, the caller could reliably use the value ofSyntaxError
to resolve the ambiguity. But if the caller decides to ignore the syntax error, it can't do anything about console output.evalNumericExpression()
fails andevalStringExpression()
runs, they both call the UDF. It runs twice.There may be others as well, but it's double-clutching the UDF that concerns me now.
This may not actually be a problem. It can always be argued, and lots of people do, that anything that has side-effects should be kept as isolated as possible. By that reasoning, a UDF should never be used in anything but a LET statement.
That's a little extreme for my taste, but at the moment, it's probably good policy. So I have two suggestions:
My new Time() function is such a case. I've compromised by checking
SyntaxError
ifevalNumericExpression()
returnsfalse
.