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: moving more cl seq/mapping support into core Date: Fri, 01 Oct 2010 13:34:50 -0700 Message-ID: <4CA645EA.3050403@gmail.com> References: <4CA52B36.6060405@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1285965307 28681 80.91.229.12 (1 Oct 2010 20:35:07 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 1 Oct 2010 20:35:07 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 01 22:35:06 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 1P1mJt-0003Lo-Jw for ged-emacs-devel@m.gmane.org; Fri, 01 Oct 2010 22:35:05 +0200 Original-Received: from localhost ([127.0.0.1]:39451 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P1mJs-0005xE-Su for ged-emacs-devel@m.gmane.org; Fri, 01 Oct 2010 16:35:04 -0400 Original-Received: from [140.186.70.92] (port=42627 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P1mJm-0005vs-W4 for emacs-devel@gnu.org; Fri, 01 Oct 2010 16:34:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P1mJm-0002WX-0r for emacs-devel@gnu.org; Fri, 01 Oct 2010 16:34:58 -0400 Original-Received: from mail-pv0-f169.google.com ([74.125.83.169]:39127) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P1mJk-0002W1-7j; Fri, 01 Oct 2010 16:34:56 -0400 Original-Received: by pvc7 with SMTP id 7so2001624pvc.0 for ; Fri, 01 Oct 2010 13:34:55 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=rGZhdWy7lVXyXNm2hUzJ5KRCQwc5wAU4ZXnoZkICGS0=; b=h79rx3QTfNG8s6udGksk8HEttv//uteRE6weI3ia9erS1iswd262s6NX2GQZQlH5hR Uq702kERlNM0klH1p26FaakWckQdkbYZUsbKq7xTlyrQYNJuUqTynJn3SSuF//41UCSB XylI9DeBGMPZSfRVFVJDyFjMbrd2VowyesEY4= 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:content-type:content-transfer-encoding; b=mpJZBkkHuTvNNuvNh18Nlbo+8o0XaaylhbZT/N+xhT71pJv3A1CjnHd3Kxws5tLW0r vpTDED96Xaz00Y0n7nUMUzMkRd6AlrvUgiaaTZAhevSnuYJavZ2S9U1baBNIsh6sdnS6 gGvZ2QFYNQB6PgOGZsDb7SxfpetpRP2Y0UwmI= Original-Received: by 10.114.36.2 with SMTP id j2mr6929014waj.117.1285965295094; Fri, 01 Oct 2010 13:34:55 -0700 (PDT) Original-Received: from [0.0.0.0] (c-67-183-23-114.hsd1.wa.comcast.net [67.183.23.114]) by mx.google.com with ESMTPS id k23sm2492945waf.5.2010.10.01.13.34.51 (version=SSLv3 cipher=RC4-MD5); Fri, 01 Oct 2010 13:34:53 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 In-Reply-To: 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:131186 Archived-At: On 10/1/2010 4:42 AM, Richard Stallman wrote: > > Those are all rather heavy things by nature, so if the calling > > sequence is heavy too, that's ok. > > If I added a `remove-if' function I would like it not to be so heavy > > to use. > > You can use compiler-macros (or an equivalent) to create "fast" calls > when the keywords involved are known beforehand, as they almost always > are. > > Indeed, one could do that. However, that doesn't mean that it is > unimportant to choose a good, convenient interface as the one we offer > and document. I understood the primary objection to keyword arguments being about efficiency. Compiler macros solve that problem. If you instead want to discuss the convenience of keyword arguments --- well, they're hard to beat. Functions that take a large number of arguments with various ad-hoc parameter meanings (I'm looking at you, write-region) are a nightmare to use, and keyword argument would greatly simplify their use (which is probably why play-sound takes keyword arguments).