> From: "Burwell, Edward" <[EMAIL PROTECTED]> > > > I use/write functions all the time. I love 'em. You can > return ANYTHING > > you want from a single digit to an array. If you have some specific > > questions, ask away.
Wendy Smoak wrote: > Can you use them in I-Descriptors? Doesn't look like it from 'Using > UniData' though I suppose you could write a subroutine that > did nothing but > call the function. Wendy, you can, but it isn't documented and it happens 'by accident' because functions are internally implemented as subroutines with an extra hidden argument at the front for the return value, just like virtual field/I-Type SUBRs need to be. Personally, I prefer not to rely on this always being the way FUNCTIONs are implemented, and I'd do what you suggest and implement a trivial wrapper SUBROUTINE to invoke the FUNCTION, but as currently implemented that is not required. Earlier in the thread you mentioned that 'we' consider SUBROUTINEs to be computationally expensive and prefer GOSUB. I suspect that 'we' includes folk who were brought up on Prime's and various other run machine implementations. I remember I first came across MV databases with INFORMATION on 50 Series at a software house that was just starting to look at Universe (PI EXL). I couldn't understand why so much of their code was rammed into big ugly programs and subroutines that started with a huge ON GOSUB and seemed to contain stuff that was completely unrelated. It turned out that INFORMATION had a 64K object code limit, and that CALLs had always been exceedingly slow because they went through the standard 50 Series 'snap' mechanism for locating routines which was always slow the first time you referenced something and could only be overcome by caching the subroutine name in a variable and calling it indirectly on subsequent attempts: X=MYSUB; CALL @X So experience with 50 Series had taught them to use as few subroutines as possible, and in each one, to pack as much code as would fit in 64K of object. Little did it matter to them that once they started to deliver their software largely on UniVerse and UniData they lost their 64K limit and the CALL 'snap' mechanism disappeared. At one point I actually did some benchmarking with their code to demonstrate that some of their GOSUBs to labels at the other end of their 64K object code took longer than an equivalent CALL to a small SUBROUTINE which did the same thing once that routine had been loaded into memory by sbcs. this was an extreme though - GOSUB is usually quicker than CALL, but not much. CALL worked out about 20 times more expensive than a variable assignment on UniData, which in my book is not worth half a days additional debugging associated with every variable having global scope within a single program. As I said, the way I understand it FUNCTIONs in UniData are just CALLs wearing a disguise, but at various points in the past there have been discussions about changing this - presumably to make them faster and better - more than one function in a source code file would be nice). Certainly they are worthwhile - you can overlay any UniData built-in function if you like: DEFFUN SYSTEM(VBLE) CALLING "MYSYSTEM" for example is a way to extend the facilities of UniData's SYSTEM function to suit code being converted off a platform that provides different SYSTEM() facilities. Cheers, Ken ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
