rc> That is the reason why I haven't taken to PG as well. > It has its benefits, but... Concerning named SUBprograms with private (static) variables, let me suggest some possible uses: -- modernize Statz' PG with a minimum of rewriting (I hope Statz is listening ;-) -- more elegantly and safely port to FB the system uses by Apple of static variables (something Herbie mentioned to me offlist). -- reduce administrative overhead of 'calling' by a factor of about 5, compared with today's FNs. rc> I was just saying that even on a fast machine, > speed of execution still matters. mark> But you then said you use Local FNs anyway, so for Compositor, at > least, the speed of execution of GOSUBs isn't fast enough in relation > to Local FNs for you to switch. I imagine that in time-critical parts rc has to disfigure his natural coding style by cutting down on the number of FN calls through inlining, GOSUBs, AND GOTOs. That code mutilation quickly becomes intolerable to me because the time critical parts are exactly the parts where I want maximum *clarity* to help me think. And RP has offered proof that the syntactical clarity provided by generous use of the FN construct is affordable once his fast FN's are implemented. The same would be true for subprograms; they would have about the efficiency of today's GOSUBs. Such improvements can easily double the speed of a program in data- or math- intensive work, and at zero cost to the programmer inasmuch as his style remains optimal. That's about the difference of power between PPC and Intel at comparable prices! Again, speed doubling is about what one expects of an accellerator card worth at least a couple of hundred $$. (It seems a lot of guys do like speed ;-) Cheers Laurent S. PS. For benchmarks on RP's fast functions, search for "GP2" in the list archives if 1991. (RP is our Robert Purves and GP2 comes from "Gariepy-Purves-mark-2").