|
On Wed, 8 Jun 2005, Larry Ducie wrote:
Anyway, I get your point. I'm just saying that IBM have already introduced BIFs that can't be used in evaluation expressions or comparative expressions so we're already on our way down that road. I'm just suggesting we go further down that road: I would rather have %evalCorr() than EVAL-CORR. We could simply have it return a value that can be discarded if required - like callp. I like the flexibility in that.
Why have it be a BIF at all? What you are describing is how normal (non-built-in) functions work. I agree with your idea completely. But then why make it a bif? In fact, following this same logic, why have any BIFs at all? Why %evalcorr() instead of evalcorr()?
I guess what I'm wondering is, what really distinguishes a BIF from just a normal function? And is that difference so important and wonderful that it should be kept?
I agree it should not be an op-code. Much better as a function. IMO, languages should generally have few op-codes (add, subtract, multiply, divide, assign, a few others) and a rich function library.
midrange.com
James Rich
It's not the software that's free; it's you.
- billyskank on Groklaw
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.
