Re: [GSoC] Parameter protocols in CL

[Helmut Eller <eller dot helmut at gmail dot com>]

On Mon, Jul 16 2012, Charles Turner wrote:

> Of these, ordinary, macro and destructuring are my priorities. Kawa
> already supports more than it needs to for ordinary lambda lists
> (modulo a couple of CL keywords). But I don't want all the extended
> Kawa processing for types etc. So I intend to subclass
> kawa.lang.Lambda for the different LL types above, removing the
> Lambda#rewriteAttrs() processing and override the Lambda#rewrite
> method. There's going to be some code duplicate here, but I don't see
> a better way to do it. I could refactor the rewrite() methods to
> reduce code duplication.

Just write your code nicely factorized.  We will see if some of those
factors can be used for the Scheme front-end later.

> For instance, the multiple keyword checking
> can be considered a method, but will there by a noticeable
> performance hit factoring rewrite into 5 or so methods?

I guess the overhead for method calls is in the noise.  Joe Armstrong
has a catchy rule for writing clean programs: "as inefficient as
possible".  Works great :-)

> It's not a
> trivial refactoring, and tbh, I don't find the code here particular
> difficult to understand. I've noticed lots of larger methods like in
> Kawa that are candidates for refactoring, but just assumed it was for
> efficiency. Not sure what the threshold is for Hotspot's method
> inliner.
>
> I'm struggling to find where the optional parameter handling actually
> happens. I.e., where it check whether a parameter has actually been
> passed and decides whether or not to use the default parameter.
> Compilation#enterFunction (sp? maybe, away from dev machine) looked
> like it does this, but the code isn't executed from an interactive
> environment IIUC. I couldn't see where in Lambda or LambdaExp it's
> happening. Any clues?

For &optional arguments you can tell it from the number of arguments.
Each argument count [argmin..argmax] gets an "entry point" (see
LambdaExp#primMethods); defaults are computed there before
(tail-)calling the "main" method with the full number of arguments.

For &keyword args a helper routine gnu.expr.Keyword#searchForKeyword is
used.  (Guess why nobody uses keyword args :-)

It seems that LambdaExp#addMethodFor decides which entry points are
needed.  Code generation happens in LambdaExp#compileAsMethod which
loops over the LambdaExp#primMethods for &optional entry points and
calls LambdaExp#enterFunction for the main entry point.

I guess for &optional arguments it's the easiest to make the supplied-p
vars a method arguments of the main entry point.  For &keyword args it
seems that gnu.expr.Keyword#searchForKeyword returns Special.dfault if
the argument was not supplied.

Helmut