Re: case-lambda integration

[Ludovic Courtès]

Hey,

Andy Wingo <address@hidden> writes:

> All args are passed on the stack. A procedure may have required,
> optional, keyword, and rest arguments. The N required arguments are
> bound to the first N local variable slots. The M optional arguments are
> bound to the next M local variable slots. If an optional variable is not
> positionally present, SCM_UNDEFINED is placed in the slot. If there are
> keywords as well, then things get complicated.

Understood.

> I wanted to allow positional arguments to also have keywords. I had to
> make a decision what to do if you have 2 required args, 1 optional, and
> 1 keyword -- if the 3rd argument is a keyword, does it go in the
> optional slot or does it start the keyword processing? I chose the
> latter. 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?

> If a rest arg is also given, it will hold all keyword args as well, and
> the rest must be a valid keyword arg list.
>
> It's quite complicated, and very much "feature on top of feature". You
> could emulate this with rest arguments, as (ice-9 optargs) does, but
> 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.

>> As you rightfully guessed I lean towards (1), but then again I don’t
>> understand how this affects the implementation.  Would option (1) be
>> somehow harder to implement, or would it tend to duplicate code or
>> something like that?
>
> So it's either introduce new identifiers (lambda* and define*) in the
> default environment, or add functionality to the existing ones. I don't
> care very much either way, TBH, though I lean to enhancing lambda.

I’m OK with the introduction of ‘lambda*’ and ‘define*’ in the name space.

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

Thanks,
Ludo’.