From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Pascal J. Bourguignon" Newsgroups: gmane.emacs.help Subject: Re: What does ":noerror" do? Date: Sun, 13 Oct 2013 16:17:06 +0200 Organization: Informatimago Message-ID: <87iox1l0gt.fsf@informatimago.com> 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: 8bit X-Trace: ger.gmane.org 1381674014 25730 80.91.229.3 (13 Oct 2013 14:20:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 13 Oct 2013 14:20:14 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Oct 13 16:20:19 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 1VVMWo-0006gZ-Iz for geh-help-gnu-emacs@m.gmane.org; Sun, 13 Oct 2013 16:20:18 +0200 Original-Received: from localhost ([::1]:33274 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVMWn-0000Xv-Mk for geh-help-gnu-emacs@m.gmane.org; Sun, 13 Oct 2013 10:20:17 -0400 Original-Path: usenet.stanford.edu!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 203 Original-X-Trace: individual.net JgWrOd3bUWSzqsRgUvvJfQpLul3IYCIBcyFxHNy/lpYthRz9Mo Cancel-Lock: sha1:YTgxZTQxZmFjZWNiZTE3NDdjOGZmOGM2MDM0NTEyNmVjZWVlYzIyZg== sha1:Y74J1HqyRxliZkLwKR8iIMyR71U= Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Original-Xref: usenet.stanford.edu gnu.emacs.help:201719 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:93987 Archived-At: Drew Adams writes: >> > (message "Loading Emacspeak...%s" >> > (if (load "emacspeak-loader" :noerror) >> > "success!" >> > "FAILED!")) >> > >> > I'm not sure what the ‘:noerror’ is. It seems that the ‘:noerror’ >> > is just like a random symbol, like ‘(quote noerror)’, but 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'. > >> 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: >> >> 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) >> >> 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. Yes more. Consider: (load file nil t nil t) vs. (load file nil :noerror nil :nosuffix) Casual reading of the later let the human programmer think that loading the file will be done without signaling errors and without suffix. Casual reading of the former cannot be done: you have to refer to the documentation to understand what is meant. Of course, we could agree that the problem here is casual reading. But then why don't we obfuscate all the symbol names before reading programs? > 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. My point was that &key arguments are more difficult to use in a misleading way for casual readers than &optional arguments. Since emacs lisp doesn't have &key arguments (unless you (require 'cl) and use defun*), I switched to Common Lisp as a good example. &allow-other-keys would be proeminently written in the function lambda list, or :allow-other-keys t would clearly appear in the argument list, so no casual reading would overlook it. > […] > Your uninspired terror is a bogeyman. I think you've not considered closely enough my other example, the one written in emacs lisp: >> (load file nil :noerror nil :nosuffix) Agreed, it's shorter than the CL example. It's hard to denote side boxes in ASCII (I could have tried some ascii art). Considering alternative languages with alternative solutions put things in perspective. > 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). Well, no. In CL the name of keyword symbols doesn't start (usually) with a colon: #+common-lisp (symbol-name :hello) -> "HELLO" #+emacs-lisp (symbol-name :hello) -> ":hello" > […] >> 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. Yes. And notably, it's considered a design error to mix &optional with &key or &rest. There are only two functions in CL that do, and only for historical and legacy compatibility reasons. > 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'). It has, with (require 'cl) (defun* …). > 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'. Yes, but since we don't ostracize the CL package when we write Common Lisp programs, we do use &key instead of &optional with kewords. > 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. No argument here. The problem is not ambiguity, it's casual reading by a human processor, vs. precise interpretation by a compiler (or attentive programmer). > 4. Since there are NO keyword parameters in Emacs Lisp, bringing > them into this discussion creates, instead of removes, confusion. Extends the horizons and propose a would be welcome evolution. > A keyword passed to an Emacs Lisp function NEVER introduces a > keyword-parameter value. And therefore always may induce the programmer in error by its name, when only its boolean value was expected, (or help the programmer understand what the boolean value means, when the name matches its meaning). Which is all the point of the original question. > 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). That may give a hint to the reader, but can still mislead in case of error. > 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. -- __Pascal Bourguignon__ http://www.informatimago.com/