Re: Keyword args

[Daniel Colascione <dan.colascione@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3712 bytes --]

On 12/10/10 12:53 AM, Helmut Eller wrote:
> * 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.

How many forwarder macros do you need to sufficiently cover the problem
space? Combinatorial explosion is a problem when the set of possible
inputs is large.

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

You're mostly right, though it's not impossible to imagine a situation
in which it's useful to APPLY a keyword-argument-parsing function.

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

Clearly, the solution is more uniform keyword argument parsing; either
library functions in C could be provided, or make-network-process could
be made a Lisp keyword-parsing front-end for some horrible
%make-network-process that implements the functionality.

Still, most functions aren't written in C, and keyword parsing is easier
in Lisp.

> 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))

The apply example isn't that bad in my book, and most of the time, you
don't need to forward an arbitrary subset of keyword parameters to
another function anyway.

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

Sure, but putting them in the lambda-list is even easier for most cases,
especially when there aren't that many arguments. It's also easier to
document functions written with &key than it is to document equivalent
functions that do ad-hoc parsing.

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

Compiler macros can eliminate the pain in this case.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]