This page is part of the web mail archives of SRFI 89 from before July 7th, 2015. The new archives for SRFI 89 contain all messages, not just those from before July 7th, 2015.
On 11-Apr-06, at 6:35 PM, John Cowan wrote:
Here are two alternative formulations of keywords, both based on theidea that keywords are pure syntax, with no representation at run time.1) Keyword-value arguments are sorted into order corresponding tothe 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 ana-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.