> [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/
