[GSoC] Parameter protocols in CL

[Charles Turner <chturne at gmail dot com>]

As expected, I ran into the supplied-p parameter stuff whilst
implementing DESTRUCURING-BIND. I could use the workarounds provided
by Helmut or Jamison a while ago, but I think it would be prudent to
fix this in some generality right now. In CL there's the following
different types of lambda lists:

Ordinary, Macro, Boa, Generic function, DEFINE-METHOD-COMBINATION,
Specialised, DEFSETF, DEFTYPE, Destructuring and DEFINE-MODIFY-MACRO.

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