[PEAK] Regular functions vs generic functions

Phillip J. Eby pje at telecommunity.com
Fri Feb 15 09:41:52 EST 2008

At 03:31 PM 2/15/2008 +1030, David Gowers wrote:
>On Fri, Feb 15, 2008 at 2:44 PM, Aaron Lebo <aaron.m.lebo at gmail.com> wrote:
> > Is it feasible (or even something you'd want to do) to only use generic
> > functions? I also noticed this line in the readme, which seemed related to
> > my current question. "These decorators also all work with existing
> > functions; you do not have to predeclare a function generic in order to use
> > it." What does that mean in practice?
>It means, there is not such a thing as a generic kind of function; The
>way things work is that the bytecode of the function is modified.

Correct.  PEAK-Rules does not require you to pre-declare a function 
as generic -- it can turn any existing function into a generic 
function, on-the-fly.

In effect, this allows you to do "generic monkeypatching".  :)

>The overhead in using generic functions, is AFAIK only this:
>The normal overhead incurred by checking the conditions (eg, is
>parameter 'color' a tuple, or is it an int?).
>So if you manually expanded the function, it would run barely faster
>(or possibly slower.).

Well, there is overhead for setting up and "compiling" the 
function.  Some of that overhead occurs at declaration time, and some 
is deferred until the next time the function is called.  Also, some 
parts of the dispatch facility (mainly comparison operators), have 
function-call overhead at the moment, although I plan to inline that 

I would expect, however, for the mechanism to be fast enough that 
it's *close* to a hand-written function's dispatch overhead, and in a 
few cases, maybe even faster.

More information about the PEAK mailing list