From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: What does ":noerror" do? Date: Sat, 12 Oct 2013 19:14:51 -0700 (PDT) Message-ID: <149ed7f3-aa0a-48d9-8236-37237f350704@default> References: <87ob6uks2p.fsf@informatimago.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1381630522 2814 80.91.229.3 (13 Oct 2013 02:15:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 13 Oct 2013 02:15:22 +0000 (UTC) To: "Pascal J. Bourguignon" , help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Oct 13 04:15:24 2013 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VVBDI-0007zG-GH for geh-help-gnu-emacs@m.gmane.org; Sun, 13 Oct 2013 04:15:24 +0200 Original-Received: from localhost ([::1]:59986 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVBDH-0007qZ-SJ for geh-help-gnu-emacs@m.gmane.org; Sat, 12 Oct 2013 22:15:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45738) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVBCx-0007ml-Tz for help-gnu-emacs@gnu.org; Sat, 12 Oct 2013 22:15:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VVBCp-00023U-Aj for help-gnu-emacs@gnu.org; Sat, 12 Oct 2013 22:15:03 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:36375) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVBCp-00023O-3f for help-gnu-emacs@gnu.org; Sat, 12 Oct 2013 22:14:55 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9D2EqIj018651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 13 Oct 2013 02:14:52 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9D2EnAB022461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Oct 2013 02:14:50 GMT Original-Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9D2En1k028284; Sun, 13 Oct 2013 02:14:49 GMT In-Reply-To: <87ob6uks2p.fsf@informatimago.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:93975 Archived-At: > > (message "Loading Emacspeak...%s" > > (if (load "emacspeak-loader" :noerror)=20 > > "success!" > > "FAILED!")) > > > > I'm not sure what the =E2=80=98:noerror=E2=80=99 is. It seems that the= =E2=80=98:noerror=E2=80=99 > > is just like a random symbol, like =E2=80=98(quote noerror)=E2=80=99, b= ut I could't > > find this kind of usage in lispref. Any ideas? Right. It is a keyword, which means that it is a symbol whose value is always itself, as is the case for `t' and `nil' (which are not keywords). It is a constant: you cannot change its value. `(setq :foo 42)' raises an error saying that you cannot set a constant. So yes, using `:noerror' here acts the same as using `':noerror'. =20 > It is a lisp object that is not the symbol nil, and therefore that > is true. That's all it takes for a boolean argument. > The doc is quite clear about it: >=20 > If optional second arg NOERROR is non-nil, > report no error if FILE doesn't exist. IOW, any non-nil value provided as the 2nd argument has the same effect. > The question is what it does to the programmer mind of the human > readers? And the answer is that this particular non-nil argument value, like `'NOERROR' is (a) as good as any other non-nil value, for the program, and (b) it says what it does, for a human reader of the code. Its name can act as a reminder to someone reading the code that the argument means "report no error if FILE doesn't exist". > I could not say about people in general. It sure looks like it > confused you. Perhaps only because keywords are not used so much in Emacs-Lisp code. It took a long time before they were even added to the language. And they still have not been added for use as keyword parameters in lambda lists. > I can tell that I think it should inspire TERROR in > every programmer minds. Think about it: > (load file nil :noerror nil :nosuffix) >=20 > At least, in Common Lisp we'd use keyword arguments writing > something like: > (load file :verbose t :print nil :if-does-not-exist nil > :external-format :utf-8) Now, there you are changing the subject radically. This use of a keyword has nothing to do with keyword arguments. And no, no such use of a keyword in Emacs "should inspire TERROR" in anyone. No more than use of `t' or `nil' or `42' should inspire terror. OK, so your point is that *IF* the function were a COMMON Lisp function, and *IF* it had defined keyword arguments (or accepted arbitrary keyword args, i.e., used `&allow-other-keys`), and *IF* one of those defined keyword arguments were `:noerror' (or `&allow-other-keys` were present) *THEN* one might expect `:noerror' to be followed by the keyword value to pass, and SO someone might be confused to see `:noerror' not be so followed. Fair enough. But off-topic. The OP asked about alligators, and you replied about non-alligators. IF...and IF...and IF... But OTHERWISE you would (should) not. And OTHERWISE is in fact the case. Your IF...IF...IF... scenario is a red herring that does not inspire terror. A non-alligator. And IF all of that were the case in Emacs Lisp (though it is not) then the doc would tell you that `&keys' is part of this function's signature, and it would show each of the defined keywords for the function, and it would show `&allow-other-keys' if appropriate. IOW, the signature would let you know whether you can expect `:noerror' as a keyword arg. Your uninspired terror is a bogeyman. Even in Common Lisp, a keyword is just a symbol (in package `keyword') whose name starts with a colon (`:') and that evaluates to itself (i.e., has a constant value). That keywords are often used in Common Lisp as keyword parameters to functions does not change the fact that they are also used as handy constant values. > But with optional arguments, the programmer must ensure that the > parameter are given in the right order, and using keywords for true > booleans may confuse this, and impact a different meaning to the > programmer than to the compiler. Terror should ensue. Certainly someone using keywords in Common Lisp needs to know how they are used as keyword parameters. But knowing that, there is no confusion. Keyword arguments are handled only after all specifiers of optional parameters have been processed. And among the keyword arguments there is no significant order when keywords are present. In sum: 1. This is Emacs Lisp, which has no keyword parameters (no `&key'). 2. Even in Common Lisp, keywords are sometimes used simply as convenient constants. As a Boolean Lisp value, for example, they can be more mnemonic than just `t'. 3. There is no ambiguity here, for either Emacs Lisp or Common Lisp. But yes, if someone is unclear about keywords then s?he could be confused. 4. Since there are NO keyword parameters in Emacs Lisp, bringing them into this discussion creates, instead of removes, confusion. A keyword passed to an Emacs Lisp function NEVER introduces a keyword-parameter value. It is ALWAYS simply a constant value passed as an ordinary (non-keyword) argument. 5. All of that said, I personally tend to use `'NOERROR' in a context like this, instead of `:noerror' or `:NOERROR'. I tend to use uppercase, and I tend to use the same name that occurs for the formal parameter in the doc string (but not always, if something better occurs to me). Your main answer is well put, however: all that matters in this particular case is that a non-nil value is passed, and for that purpose `:noerror' is as good as any other non-nil value.