[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Difficulty with lambda-list congruence, specifically &KEY
- To: firstname.lastname@example.org
- Subject: Re: Difficulty with lambda-list congruence, specifically &KEY
- From: kanderso@DINO.BBN.COM
- Date: Mon, 12 Mar 90 12:23:40 -0500
- Cc: commonloops.pa@Xerox.COM
- In-reply-to: Your message of Mon, 12 Mar 90 08:36:00 -0600.
- Redistributed: commonloops.pa
Date: Mon, 12 Mar 90 08:36 CST
>From: ihlpf!lgm (Lawrence G Mayka +1 708 713 5166)
Subject: Re: Difficulty with lambda-list congruence, specifically &KEY
>Don't forget that processing &key arguments is expensive, you probably
>don't want to do it for every function call.
Ideally, only methods that actually use the keyword arguments need
to "process" them. Older methods need merely discard the (unused)
In a good LISP, that might be true. In the LISP i use,
(defun foo (x &key y z) (declare ignore y z) x)
is 3.4 times slower than
(defun foo (x) x).
because the argument list is processed, keywords verified, and given
default values before the body of the function runs.
More importantly, our criteria of extensibility, upward
compatibility etc. need not apply to all function calls, only to
generic functions that represent interfaces between software
Yes, hopefully it will be obvious which functions in a protocol
will require keyword arguments, so the problem you are talking about
will be relatively rare.
>I don't think that adding &key's will provide all the extentability
>you'll need in an evolving system.
No, but together with the other features of ANSI Common Lisp and
CLOS, they can go a long way.
>Why not let your protocol evolve over time. Your 1995 code could have
>keywords, and your 1990 methods could be redefined to call the 1995
>methods with default arguments.
A prime criterion is to evolve the system without disturbing old
code. Changing old code can break existing features - an
intolerable catastrophe as far as our customers are concerned.
Besides, engineering constraints (e.g., continuous uptime,
real-time response) encourage the redefinition of as little code
This is a demanding environment. How do you distribute and install
bug fixes and new versions?
Perhaps the opposite of my suggestion might work - write the new
software in terms of the old methods. So, now say, you are using
(FOO X), and you realize you need (FOO-91 X &KEY Y Z). Your new
software can use FOO-91 and the old can continue to use FOO. You
you want to refer to both versions as FOO, you could use a macro or
something to hide the differences.