When I said 'hack' I meant the ugly code that I had to create to make the trick work--the idea of having to put a dummy parameter into the function call in the basic program in order to make it compatable with the subr call in the i-type. Sorry for the confusion there.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Wallis Sent: Friday, June 24, 2005 9:04 PM To: [email protected] Subject: RE: [U2] Custom Functions > [EMAIL PROTECTED] wrote > So you can mix and match between treating it as a subroutine and as a > function, but the function version always has one less argument - the > first one is missing as it is an "implied" result. > > Someone said "don't risk this because it may change in future". As far > as I'm aware, it WON'T change, because the SUBR call relies on this > behaviour. Look up SUBR in the docu, and you'll see that anything it > calls MUST be this sort of function, after all, when you call a > subroutine using SUBR, you can't pass in the first argument ... Wol, it was me that said "don't assume this will always be how it works". I think you missed my point. I wasn't saying that the SUBR() interface from I-types might change - why should it? What I was saying is that you shouldn't assume that the only way to implement FUNCTION was as a SUBROUTINE with an extra hidden argument, and you shouldn't assume that the only way to implement RETURN X was to set that hidden argument to the value of X. It appears to me from Wendy and Ed's investigations that UniData has indeed made a change somewhere since 4.1 when I last looked at this in detail such that there is no hidden extra argument on a FUNCTION and that RETURN X actually puts X on the stack somewhere. I stand by my comment: the way FUNCTION is currently implemented on both UniVerse and UniData is undocumented and should not be relied upon. If you want a FUNCTION which can also be called as a SUBR then code for it - write a wrapper for one or the other. Separately, Ed seems to have decided that UniData not following this undocumented mode of operation is a deficiency in UniData. I don't see it that way, but he's entitled to his opinion. On further inspection, I'm not even sure that what he identifies as a hack really is. The only undocumented feature in his program is that he successfully does a DEFFUN for a SUBROUTINE and then invokes the FUNCTION. The UniData documentation for DEFFUN *never* mentions the possibility that a SUBROUTINE can be referenced. All it mentions is FUNCTION. The doco on FUNCTION never suggests that FUNCTIONs map to SUBROUTINEs with an extra hidden argument. Anyway, I really don't want to go near the 'why buy UD instead of UV' discussion. There used to be a heap of reasons, but a lot have been flattened out in the various mergers and acquisitions. Discussions on this list do very occasionally throw up something UV has which I think would have been nice in UD - SEEK and REVREMOVE are examples, but UD still has some nice things that UV doesn't - GETENV, DIR and PCPERFORM come to mind. The only thing I will say before moving quickly along is 'indexes'. Cheers, Ken ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
