We have two tasks at generic function invocation time:
Turn the list of required arguments into a list of generalizers
Compute a list of "effective arguments" for the effective method (e.g. pattern specializers inject variable bindings at this point)
The first task is handled via either
generalizer-of-using-class gf arg
Has the advantage of simplicity
or a combination of generalizers-of-using-class gf args and generalizer-of-using-class gf arg
Has the disadvantage of complexity but is more powerful and can be more efficient. For example, the pattern-specializer implementation has a method which basically does (mapcar #'funcall list-of-generalizer-computation-functions args) without generic function calls for individual arguments.
Potential improvements:
For the first approach, change generalizer-of-using-class gf arg to generalizer-of-using-class gf arg arg-position to allow processing based on the position of the argument. This would allow performing processing of arguments based on their position like in the pattern-specializer example above.
Change generalizers-of-using-class gf args to generalizers-of-using-class gf args num-required to avoid consing up the list of required arguments at invocation time. This can be applied to both approaches.
The current implementation can be improved by closing over the number of required arguments in the discriminating function instead of computing it at invocation time.
The second task is not currently handled in the master branch
One solution could be a new protocol function compute-effective-arguments-function gf num-required which would return a function with lambda-list (args generalizers) which would in turn produce the "effective argument list" when called, for example by injecting additional arguments.
We have two tasks at generic function invocation time:
Compute a list of "effective arguments" for the effective method (e.g. pattern specializers inject variable bindings at this point)
The first task is handled via either
generalizer-of-using-class gf argHas the advantage of simplicity
generalizers-of-using-class gf argsandgeneralizer-of-using-class gf argHas the disadvantage of complexity but is more powerful and can be more efficient. For example, the
pattern-specializerimplementation has a method which basically does(mapcar #'funcall list-of-generalizer-computation-functions args)without generic function calls for individual arguments.Potential improvements:
generalizer-of-using-class gf argtogeneralizer-of-using-class gf arg arg-positionto allow processing based on the position of the argument. This would allow performing processing of arguments based on their position like in thepattern-specializerexample above.generalizers-of-using-class gf argstogeneralizers-of-using-class gf args num-requiredto avoid consing up the list of required arguments at invocation time. This can be applied to both approaches.The second task is not currently handled in the master branch
One solution could be a new protocol function
compute-effective-arguments-function gf num-requiredwhich would return a function with lambda-list(args generalizers)which would in turn produce the "effective argument list" when called, for example by injecting additional arguments.