Hey, Andy Wingo <wi...@pobox.com> 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’.
