[Top][All Lists]

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

Re: case-lambda integration

From: Ludovic Courtès
Subject: Re: case-lambda integration
Date: Tue, 13 Oct 2009 22:35:28 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)


Andy Wingo <address@hidden> writes:

> In order to expose the case-lambda functionality to Scheme though, we
> need a way to make lambdas with more than one case; so I think I will
> export case-lambda as an identifier by default.
> That is probably uncontroversial.

It’s fine with me, so certainly uncontroversial.  ;-)

> But what might be is that while I was at it, I made allowances for
> efficient optional and keyword argument dispatch -- so we can have
> keyword arguments without consing, and arguments which are positionally
> optional yet can have keywords. This is so lambda* and define* can be
> implemented nicely.

I threw a glance at the branch (in particular “flesh out glil support
for optional and keyword arguments”), but it’s unclear to me how it
works.  The callee reserves space on the stack for its parameters, but
how are keyword parameters associated with a reserved slot on the stack?

> There are hooks in <lambda-case> for these, but again the question is
> how to expose to Scheme. As I see it there are two options:
>    1. Implement lambda* (and define*) in psyntax
>    -or-
>    2. Make the stock lambda accept #:optional, #:keyword, et al
>       arguments (also a hack to psyntax)
> I'm kindof leaning towards (2) actually. But I could go either way. Both
> ways expose lambda* capability in the default environment -- because
> psyntax boots before modules have booted, and these things need access
> to psyntax internals.

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?

> Perhaps we should do (1) in the interest of interoperability; but you
> still have to know you want to code portable Scheme in order to code
> portable Scheme. Dunno.

Yes, right.

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?


reply via email to

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