|
Hi Larry, On Tue, 7 Jun 2005, Larry Ducie wrote:
In fact I'd go further, and abandon all new opcodes. I'd prefer it to be implemented as a BIF: %evalCorr(myFirstDS:mySecondDS);
The only problem I have with that idea is that it's not a function. That is, it doesn't return a value! All other BIFs return something, and therefore they make sense to use in an expression.
midrange.com
For example:
MyString = 'The number is ' + %char(Number);
However, that doesn't seem to be the case with EVAL-CORR. Since EVAL-CORR
doesn't return anything, it would not make any sense in an expression.
The following statement makes absolutely no sense:
MyString = 'blah ' + %evalCorr(FirstDS: SecondDS);
Since BIFs all work in an expression, how would you call %evalCorr() if it
didn't return anything? You couldn't use it in an EVAL statement, since
there'd be no way to assign it to a variable. You couldn't use it
anywhere else you had an expression, either.
So, I guess, you're suggesting that CALLP be extended to support BIFs. In which case, %evalCorr would be the *only* BIF to be callable through this interface.
Seems to me that having an opcode like EVAL-CORR (although I despise that name as well!!!) would be a lot more consistent with the rest of the language than making it a BIF. Making it a BIF makes no sense at all.
Instead, just come up with a decent opcode name.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
