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