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").