This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: [GSoC] Parameter protocols in CL
On 07/17/2012 03:19 PM, Charles Turner wrote:
I'm still struggling to figure this out. For an expression like:
((lambda (&optional (a 1) (b 2)) (list a b)) 10 20)
I struggle to follow the code to what happens. I *think* something like:
meth0 () { meth2(1, 2); }
meth1 (a) { meth2(a, 2); }
meth1 (b) { meth2(1, b); } // this one doesn't exist
meth2 (a, b) { list(a, b); }
The meth1(b) method doesn't exist - what would it be used for?
If there are 1 arguments, it is assigned to a, and b defaults to 2.
(It's different with keyword parameters, but that's a separate ball of wax.)
And your suggestion is something along the lines of:
meth0 () { meth2(1, 2, false, false); }
meth1 (a) { meth2(a, 2, true, false); }
meth1 (b) { meth2(1, b, false, true); } // Again: can't happen
meth2 (a, b, asup, bsup) {
initialise asup and bsup declarations with appropiate lang bools.
list(a, b);
}
That's what I think should happen, as for generating the method
parameters, I'm still not confident I know how to do that.
I'm not sure how important it is to handle the supplied-p-parameter
parameter. I suspect it isn't used that much. Unless something
important depends on it, I suggest leaving for me to deal with as
part of the pattern-matching support.
Per, re the "code not executed" point, what I said was not what I
meant :-). The code starting from line 1440 in LambdaExp#enterFunction
looks like it does exactly what I'm talking about, consulting the VM
registers and acting on that information. *This* code is not executed,
because the
if (plainArgs >= 0 || ! param.isSimple()
|| param.isIndirectBinding())
condition is not satisfied with the examples above.
That is (I think) because this is handled by generating multiple methods,
combined with the generated "apply" methods - see
Compilation#generateApplyMethods*.
I.e. apply0 calls meth0; apply1 calls meth1, apply2 calls meth2.
Try not to get bogged down into this. The apply methods are also
likely to change for various reasons. So just try to translate
the Common Lisp forms into whatever LambdaExp forms that Scheme
would. Don't try to add to or enhance the parameter handling: It's
complicated, and it may change soon.
Also, in (&optional (a 2 a-p)), I'm making a Declaration out of A-P
and adding it to the A declaration (a new field in Declaration). This
really doesn't feel right,
It isn't right.
but how else are you going to associate the two declarations?
They're associated from being in the same LambdaExp.
I'm running into a similar issue with pattern matching. For example:
(define (reverse2 [a b])
[b a])
Here you have two Declarations a and b, neither of which match an
incoming parameter, but which are *extracted* from the incoming
parameter (which is a third anonymous Declaration).
I've got code to support this kind of pattern matching, though
it's pretty incomplete and buggy.
This is similar to having two Declarations for a and a-p matching
either one or zero incoming parameters. So let's leave that
until the pattern-matching framework is closer to working.
Apologies for the lack of learning curve crampons.
There's a lot of stuff - in both Common Lisp and in Kawa!
--
--Per Bothner
per@bothner.com http://per.bothner.com/