The issues you raise appear to be related to named optional
parameters so I am replying on the SRFI 88 and SRFI 89 lists.

On 11-Apr-06, at 6:35 PM, John Cowan wrote:

> Here are two alternative formulations of keywords, both based on the
> idea that keywords are pure syntax, with no representation at run
> time.
>
> 1) Keyword-value arguments are sorted into order corresponding to
> the alphabetical order of the keywords.  Thus  (foo 'bar foo: 32
> bar: 54)
> comes out at run time as (foo 'bar 54 32).  Similar treatment is
> given to keywords in lambda lists.  (Note: forcer came up with this
> one independently.)
>

But doesn't this require that all named parameters be supplied?  So
it does not help with named optional parameters.  The error checking
is also very poor.

BTW: Who is forcer?

> 2) Keywords are syntactic sugar for a single argument in the form
> of an
> a-list.  This maps (foo 'bar foo: 32 bar: 54) to
> (foo 'bar '((foo: . 32) (bar: . 54))).  Keywords in lambda lists are
> initialized by unpacking the a-list when the procedure is invoked.

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

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.  Of course, in the very common case
that the keywords are specified directly the compiler can optimize
the call.

Marc