Hi Ludovic,
On Thu 22 Oct 2009 00:00, l...@gnu.org (Ludovic Courtès) writes:
> Andy Wingo <wi...@pobox.com> writes:
>
>> So once you run out of optionals or see a keyword, the remaining
>> arguments are shuffled up on the stack, to be placed above the empty
>> slots for keyword arguments -- /if any/. Then the keyword arguments are
>> traversed, looking at the keyword alist ((#:KW . N) ...), to determinine
>> the local slot that a given keyword corresponds to. If no slot is found,
>> that may be an error or it may be ignored -- depending on the
>> allow-other-keywords? option.
>
> So the keyword alist is new meta-data stored alongside the procedure,
> right?
Yes. It is stored in the procedure's object table.
The metadata itself does change on this branch. Before the metadata was
a thunk returning (BINDINGS SOURCES . PROPERTIES); now the thunk returns
(BINDINGS SOURCES ARITIES . PROPERTIES). Arities is an
extents-delimited description of the procedure's arities, for debugging
and printing purposes.
>> with callee-parsed arguments we can make keyword arg procedures pay for
>> it, but without the cost of allocation on each procedure call.
>
> ... which sounds like a big win to me. That means one would be less
> hesitant in using keyword arguments, which is good IMO.
Yes, I think so too! Keyword args are a big win for maintainability of a
library, IMO -- and this makes kwargs first-class citizens of Guile at
the same time as making them faster.
>> So it's either introduce new identifiers (lambda* and define*) in the
>> default environment, or add functionality to the existing ones.
>
> I’m OK with the introduction of ‘lambda*’ and ‘define*’ in the name
> space.
OK. There will also be case-lambda and case-lambda*.
One more thing in lambda* -- I have added a #:predicate option, so that
this particular lambda case only matches if evaluating the predicate in
the lexical context of the arguments returns a true value.
This should allow:
(typecase-lambda
(((a <foo>) (b <bar>))
(specific-frob a b))
((a b)
(general-frob a b)))
=> (case-lambda*
((a b #:predicate (and (eq? (class-of a) <foo>)
(eq? (class-of b) <bar>)))
(specific-frob a b))
((a b)
(general-frob a b)))
Thus it allows effective-method implementation in Scheme and not
using evaluator #...@dispatch hacks :-)))
>>> OTOH, how difficult would it be to accommodate different keyword
>>> argument APIs, such as ‘(ice-9 optargs)’, SRFI-89, and DSSSL, which have
>>> subtle differences, once we have built-in support for one flavor?
>>
>> The Scheme interface will be the same as optargs, I think -- possibly
>> with some extensions.
>
> So (ice-9 optargs) could very much be deprecated? There may be subtle
> corner cases needing attention, though.
Sure that would be possible. For 1.8 -> 2.0 reasons we can just make
optargs re-export lambda* from the base environment, and deprecate
optargs in 2.2.
Andy
--
http://wingolog.org/
