guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: case-lambda integration


From: Andy Wingo
Subject: Re: case-lambda integration
Date: Thu, 22 Oct 2009 09:41:58 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux)

Hi Ludovic,

On Thu 22 Oct 2009 00:00, address@hidden (Ludovic Courtès) writes:

> Andy Wingo <address@hidden> 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 address@hidden 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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]