[PEAK] Regular functions vs generic functions

[Phillip J. Eby]

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 
eventually.

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.