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

Re: Alternative formulations of keywords



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