From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Keyword args Date: Sun, 12 Dec 2010 18:10:46 -0800 Message-ID: <4D0580A6.7090307@gmail.com> References: <87mxojwu15.fsf@uwakimon.sk.tsukuba.ac.jp> <87k4jnweng.fsf@uwakimon.sk.tsukuba.ac.jp> <87d3pdwt1x.fsf@uwakimon.sk.tsukuba.ac.jp> <87bp4x37ey.fsf@lola.goethe.zz> <874oapwnon.fsf@uwakimon.sk.tsukuba.ac.jp> <4D01D9D8.5040400@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig53FB682369022F2D4126ABB9" X-Trace: dough.gmane.org 1292206269 16335 80.91.229.12 (13 Dec 2010 02:11:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 13 Dec 2010 02:11:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 13 03:11:01 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PRxsS-0004Mq-PF for ged-emacs-devel@m.gmane.org; Mon, 13 Dec 2010 03:11:01 +0100 Original-Received: from localhost ([127.0.0.1]:47168 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PRxsS-0005ck-83 for ged-emacs-devel@m.gmane.org; Sun, 12 Dec 2010 21:11:00 -0500 Original-Received: from [140.186.70.92] (port=41425 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PRxsN-0005cf-TA for emacs-devel@gnu.org; Sun, 12 Dec 2010 21:10:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PRxsM-0007gd-J0 for emacs-devel@gnu.org; Sun, 12 Dec 2010 21:10:55 -0500 Original-Received: from mail-pv0-f169.google.com ([74.125.83.169]:32863) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PRxsL-0007dI-SV for emacs-devel@gnu.org; Sun, 12 Dec 2010 21:10:54 -0500 Original-Received: by pvc30 with SMTP id 30so1539599pvc.0 for ; Sun, 12 Dec 2010 18:10:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type; bh=qcAZ/CqngQqqBR1KnEpeNoZ6ehRu6Hul7kMrCrRx3ns=; b=E7r8Bcxypu/oS2HtDeDhq9v8xau7n5+SPdWXXhjm8wNgqYSYfq/cR2tWr2jkW9gt91 W2Nh4OfDEDkU+DsUPC4naC0UrbfrnGJ0ZM2+oWwVcAawEpnEELvMt/Gl9sdiJnnv83kP QZXp43KQ0z324ES9aYaYPQccFfL5GQ5E3Zkx0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; b=FI/Mk07p81TPlrfEo0EQUHk/625Yvqsb5aVcFLvEq/IQ+0KXY5+lJzeaz9KBEaFNxG 0MiIc6+2BaFz7vzpj2hq0KHh1G0AL9RuRkFAOSigqRer7Hno5/GJkYa3n63p78k/4fPp n2eyEPaStq4oYCU6L0oPTIiDlvU/m5EKd6wLM= Original-Received: by 10.142.152.1 with SMTP id z1mr2741156wfd.398.1292206252301; Sun, 12 Dec 2010 18:10:52 -0800 (PST) Original-Received: from edith.local (c-67-183-23-114.hsd1.wa.comcast.net [67.183.23.114]) by mx.google.com with ESMTPS id v19sm8225715wfh.0.2010.12.12.18.10.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 12 Dec 2010 18:10:51 -0800 (PST) User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 In-Reply-To: X-Enigmail-Version: 1.1.1 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:133633 Archived-At: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig53FB682369022F2D4126ABB9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/10/10 12:53 AM, Helmut Eller wrote: > * Daniel Colascione [2010-12-10 07:42] writes: >=20 >> 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 ar= e >> both numerous and overloaded; specific functionality can be more simpl= y >> expressed with using keyword arguments.=20 >=20 > 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 wit= h > 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. >=20 > 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. >=20 > (defun foo (x y plist)=20 > (bar x y)=20 > (baz plist)) >=20 > is IMO more readable than: >=20 > (defun* foo (x y &key key1 key2 key3) =20 > (bar x y)=20 > (baz :key1 key1 :key2 key2 :key3 key3)) >=20 > or the rather silly >=20 > (defun* foo (x y &rest plist &key key1 key2 key3) > (bar x y)=20 > (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. >=20 > 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. >=20 >> 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. >=20 > 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. --------------enig53FB682369022F2D4126ABB9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk0FgKgACgkQ17c2LVA10VstLwCfV0n+/6tzEe++yugMPRqVWEQP 2yIAoOjPpI8yK9dIUVkbxtOpvSqrVnwb =WwgN -----END PGP SIGNATURE----- --------------enig53FB682369022F2D4126ABB9--