Re: Difficulty with lambda-list congruence, specifically &KEY

[kanderso@DINO.BBN.COM]

  From: lgm@ihlpf.att.com
  Date: Mon, 12 Mar 90 08:36 CST
  >From: ihlpf!lgm (Lawrence G Mayka +1 708 713 5166)
  To: kanderso@DINO.BBN.COM
  Cc: commonloops.pa@xerox.com
  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)
  keyword arguments.

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
  components.

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
  as possible.
  
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.

k