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

Re: Alternative formulations of keywords

This page is part of the web mail archives of SRFI 88 from before July 7th, 2015. The new archives for SRFI 88 contain all messages, not just those from before July 7th, 2015.



Marc Feeley scripsit:

> For your purposes, wouldn't it be sufficient to use a rest parameter  
> in the definition of foo and parse that in foo?
> 
>    (define (foo a . rest)
>      (let ((optionals (alistify rest)))
>        ...))
> 
> Note that this is what the reference implementation of SRFI 89 does.   
> Then there is no need for the compiler to treat keywords specially  
> (except they need to be self evaluating).

Well, that amounts to using a disembodied property list rather than an
a-list to represent the keys and values.  P-lists require fewer pairs,
but all R5RS systems come with a-list manipulating functions as standard
equipment.  I'm okay with either provided one is standardized.

> Also, consider the function definition:
> 
>    (define (f a b #!key (y 11) (z 22)) ...)
> 
> and the call:
> 
>    (f x: 33 z: 44 y: 55)
> 
> In this case, I want parameter a to be bound to x: and b to be bound  
> to 33.  I don't see how this would work with your proposals.

I consider that to be a Wrong, namely, a mismatched number of arguments.
If you wish to do that, write (f 'x: 33 z: 44 y: 55).  Keyword syntax
is reserved for keyword-argument construction.

> In summary, I fail to understand which problem you are trying to  
> solve with proposal #2.  

It eliminates keywords as a run-time object in favor of symbols, and
provides a standard run-time representation of a sequence of keywords
and values as a list of some sort.

> I also don't understand proposal #3.

In proposal #3, the use of keywords in procedure calls means that you
are calling a procedure of a different *name*, and the use of them in
DEFINE-definitions (as opposed to general lambda lists) means that you
are simultaneously defining 2^k variants with separate names.  Since the
mapping to the name is documented, you are free to define overriding
individual variants, and free to use the special name directly.

Thus (from x delete: y test: z) is syntax sugar for (from:delete:test:
x y z), and (define (from x #!key delete test) ... ) defines the names
FROM, FROM:DELETE:, FROM:TEST:, and FROM:DELETE:TEST:.  In all but the
last of these, variable(s) are locally bound to the default value.

-- 
A mosquito cried out in his pain,               John Cowan
"A chemist has poisoned my brain!"              http://www.ccil.org/~cowan
        The cause of his sorrow                 cowan@ccil.org
        Was para-dichloro-
Diphenyltrichloroethane.                                (aka DDT)