Marc Feeley scripsit:

> But doesn't this require that all named parameters be supplied?  So
> it does not help with named optional parameters.

No, it merely requires the existence of a run-time object that
uniquely represents "unsupplied value".

> The error checking is also very poor.

I don't understand this point.

> BTW: Who is forcer?

Jorgen Schaefer.

> Are you saying that the programmer writes
>
>      (foo 'bar foo: 32 bar: 54)
>
> and the compiler transforms this to
>
>      (foo 'bar (list (cons 'foo: 32) (cons 'bar: 54)))

No, to a literal, not a run-time constructor.

> This seems to be an implementation of named optional parameters, so
> it is unclear to me what you are criticizing in the specification of
> the SRFI.  However I should say that a compile time handling of
> keywords will not work in general.  Think of:
>
>      (foo 'bar (f 11) 32 (b 22) 54)
>
> where f returns foo: and b returns bar: .  A general implementation
> of SRFI 89 must parse the list of parameters at run time because some
> of the keywords may be computed.

What are the use cases for computed keywords?

--
All Gaul is divided into three parts: the part          John Cowan
that cooks with lard and goose fat, the part            http://ccil.org/~cowan
that cooks with olive oil, and the part that            xxxxxx@ccil.org
cooks with butter. -- David Chessler