Just to summarize the context (per our phone discussion and for the benefit of the next time this comes up), the problem revolved around the desire to detect whether an OUTPUTONLY parameter was actually passed, so that the function could decide whether to carry out related actions (probably motivated by performance concerns, but possibly by semantic/algorithmic concerns as well). In the original implementation of named parameters, there wasn't any good way to detect, using the example above, whether the
rowct parameter was actually passed. (The argument structure is an array, such that the only practical way to handle named and optional parameters is for the compiler to fill out the call with as many dummy parameters as needed so that the function gets the complete argument array. In other words, it appears to the function that every argument was passed.)
So we settled on a kind of workaround, i.e. to allow the value of the OUTPUTONLY parameter to be passed in from the caller, and then use an unexpected default value (-1 in this case) to distinguish between the two cases. If the caller did not pass the
rowct parameter, then it would show up inside the function as the default value -1; otherwise it would show up as whatever the caller passed (presumably anything but -1).
The problem with that workaround was that it rendered OUTPUTONLY essentially meaningless.
Some time later, we came up with a better solution,
ARGTYP_READONLY, which allowed the function to test if the argument was passed as a variable or a stack expression (which would be tagged as ARGTYP_READONLY). That's not a perfect test, since it doesn't distinguish between a call where the parameter is set to a literal value, and a call where the parameter isn't even specified. But in conjunction with some kind of application-determined "special value" (-1 in this case), it's practically enough to satisfy the original objective. (Especially considering that there isn't any point in returning a value that was passed as a literal or stack expression, i.e. readonly.)
The problem with that workaround is that the OUTPUTONLY would lead programmers into the false belief that the parameter would always start out with the initial default value, when actually it was getting initialized by the caller. This can be illustrated by expanding the example above, slightly...
MAP1 row,f,8
MAP1 crlf$,s,2,chr(13)+CHR(10)
CALL fn'test(s$="asdf", rowct=row)
? row
CALL fn'test(s$="asdf", rowct=row)
? row
FUNCTION fn'test(s$="" as s0:INPUTONLY,qtype=0 as f6:INPUTONLY,rowct=-1 as f6:OUTPUTONLY) as f8
rowct += 1
xputarg @rowct
ENDFUNCTION
Now, the second call will return a different row value than the first call, even though the calls are identical and the parameter in question is OUTPUTONLY!
A secondary problem was that a programmer in-the-know would have to resort to separate, explicit initialization of the parameters, for example...
FUNCTION fn'foo(rowct=0 as f6:OUTPUTONLY)
rowct = 0 ! (why is this necessary?)
...
ENDFUNCTION
Another programmer would come along and look at this code and wonder whether either the original programmer didn't know what he/she was doing (i.e. whether it was necessary to re-initialize the parameter despite the OUTPUTONLY qualifier and default value), leading to further confusion and code that either wasn't necessary or wasn't understood.
So I "fixed" the problem in compiler edit 1047/1048, making OUTPUTONLY behave as its name suggests. But that broke an unknown number of functions in the field that were dependent on the original workaround behavior. (Hence Stephen's post.)
Even though it's painful, I think the best way forward is to find and fix the code based on the prior, logically-deficient workaround, so we can move forward with an OUTPUTONLY that lives up to its name. But to facilitate that, we need some way to flag the routines that are subject to the problem, and perhaps provide a better way of detecting if a parameter was specified.
For the first part, the best idea we've come up with so far is to limit the allowable default values for OUTPUTONLY parameters to 0, "", or .NULL. That takes away a slight bit of exotic flexibility, but is consistent with the way ASB variables are pre-initialized. In most cases, that would be equivalent to just eliminating the default value for OUTPUTONLY params. (The only point of specifying a default value would be to make any other argument that didn't have a default value be treated as mandatory. See
Named Parameters for an explanation of this seeming quirk.) So that would mean that the above fn'test() function declaration would generate a compiler error (because of the default value of -1). It would be an annoyance to stumble on this during a routine compile to update something else, but at least then you'd know to fix it. (On a side note: this issue is entirely on the compiler side, so the problem caused by the changes in the compiler would not surface until you recompiled.)
For the second part, it would probably be nice to have a new function or macro to detect if an argument was passed, i.e.
ARG_PASSED(param). The fn'test() function above could then be revised as follows...
FUNCTION fn'test(rowct as f6:outputonly)
if ARG_PASSED(rowct) then
....
xputarg @rowct
endif
ENDFUNCTION
Ideally, this function would actually be implemented as a macro by the compiler using existing runtime tokens so that it didn't require a runtime update for any program recompiled with it. But I'm not sure if that can be accomplished.
Short of that, it would make the fix slightly easier if there was a convenience compiler macro ARG_READONLY(param), which would probably cover 99% of the cases where you even cared ...
FUNCTION fn'test(rowct as f6:outputonly)
if ARG_READONLY(rowct) then
....
xputarg @rowct
endif
ENDFUNCTION
Such a macro could be handled entirely by the compiler so that it had no dependency on the runtime.
Given the complexity of this entire issue, and the fact that we are now on the second or third go-around trying to get it right, I think I'm going to try to ponder it for a day or so before doing anything rash. Additional ideas or concerns would be welcome in the meantime!
