Keyword args (was: Return)

[Helmut Eller <eller.helmut@gmail.com>]

* Daniel Colascione [2010-12-10 07:42] writes:

> On 12/7/10 8:30 AM, Stephen J. Turnbull wrote:
>> David Kastrup writes:
>> 
>>  > I don't think anybody minds the features.
>> 
>> IIRC rms has recently declared his dislike for CL-style keyword
>> arguments.  I suppose that's part of the "syntactic complexity" you
>> mention, but MON KEY OTOH points out cases where he'd like to use
>> them.  So there are some fundamental disagreements here.
>
> I'd just like to add my support for keyword arguments. Functions like
> write-region are both horrible and brittle because their parameters are
> both numerous and overloaded; specific functionality can be more simply
> expressed with using keyword arguments. 

You always have the option to make a macro with keyword arguments which
expands to a call to the "raw" function.

The only disadvantage of this approach is that macros can't be used with
higher order functions, ala mapcar.  But keyword arguments a rarely
useful in that case.

> Precedent can be seen in play-sound, defcustom, and elsewhere.

For a bad example see make-network-process.  That takes keyword
arguments but the keyword parsing is done in C and it doesn't do a good
job.  It doesn't detect invalid keywords; doesn't detect conflicting
keys; some keys are documented to be ignored when some other keys are
supplied.  It's very difficult to use.  Correct keyword parsing in C is
difficult so I would vote against it.

Also note that defcustom is a macro and play-sound takes a plist.  The
plist idiom is IMO superior to keywords.  In particular passing
arguments along gets easier.  E.g.

(defun foo (x y plist) 
  (bar x y) 
  (baz plist))

is IMO more readable than:

(defun* foo (x y &key key1 key2 key3)    
  (bar x y) 
  (baz :key1 key1 :key2 key2 :key3 key3))

or the rather silly

(defun* foo (x y &rest plist &key key1 key2 key3)
  (bar x y) 
  (apply #'baz plist))

Since we have destructuring-bind parsing plists is not very hard.

> The performance arguments opposing
> keyword arguments don't seem to be supported by benchmarks, and in any
> case, most functions, especially ones with rich functionality, aren't on
> the fast path.

The sequence functions find, position, assoc*, member* etc. are on the
fast path.  Ironically those are the functions where keyword args are
very useful because the meaning is relatively consistent.

Helmut