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: Sun, 13 Oct 2013 09:27:32 -0700 (PDT) Message-ID: References: <87ob6uks2p.fsf@informatimago.com> <87iox1l0gt.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 1381681685 4655 80.91.229.3 (13 Oct 2013 16:28:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 13 Oct 2013 16:28:05 +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 18:28:05 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 1VVOWS-0004et-Dd for geh-help-gnu-emacs@m.gmane.org; Sun, 13 Oct 2013 18:28:04 +0200 Original-Received: from localhost ([::1]:33766 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVOWR-0002xF-T5 for geh-help-gnu-emacs@m.gmane.org; Sun, 13 Oct 2013 12:28:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55756) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVOWA-0002wv-Nw for help-gnu-emacs@gnu.org; Sun, 13 Oct 2013 12:27:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VVOW3-00023X-Fe for help-gnu-emacs@gnu.org; Sun, 13 Oct 2013 12:27:46 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:38340) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVOW3-00023P-7G for help-gnu-emacs@gnu.org; Sun, 13 Oct 2013 12:27:39 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9DGRXp6006727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 13 Oct 2013 16:27:35 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9DGRUJa011247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Oct 2013 16:27:31 GMT Original-Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9DGRUqK011240; Sun, 13 Oct 2013 16:27:30 GMT In-Reply-To: <87iox1l0gt.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: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 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:93992 Archived-At: > Consider: (load file nil t nil t) > vs. (load file nil :noerror nil :nosuffix) >=20 > Casual reading of the later let the human programmer think that > loading the file will be done without signaling errors and without > suffix. >=20 > Casual reading of the former cannot be done: you have to refer to > the documentation to understand what is meant. Using perverse naming, one can mislead a reader. So what? Is that a reason not to try to use names to help readers? With that logic, why not name all functions and variables just `a',`b',...`aa',`bb',...? > Of course, we could agree that the problem here is casual reading. No. The real problem is perverse writing. Whoever writes :noerror to stand for parameter NOMESSAGE and :nosuffix to stand for parameter MUST-SUFFIX is the problem. Even an attentive reader can be thrown off by perverse naming. Yes, of course such a writing mistake could be just that: a mistake (an extra first nil, for instance). That's no different from other coding or commenting mistakes. > But then why don't we obfuscate all the symbol names before reading > programs? Indeed. Why don't we add misleading comments everywhere and rename all functions and parameters perversely, to confuse readers of even correct code? Can you guess the answer? That's the point: use names to help, not to hinder. > My point was that &key arguments are more difficult to use in a > misleading way for casual readers than &optional arguments. I don't think you said anything of the kind. And if you did, it is off-topic. No one suggested that &optional args are more difficult to use in a misleading way for casual readers than are &key args. Nothing of the kind. You brought &key into this. And Emacs Lisp has no &key. And the day that we add &key to Emacs Lisp you can be sure that it will be well documented, just as in Common Lisp. > Since emacs lisp doesn't have &key arguments (unless you (require > 'cl) and use defun*), I switched to Common Lisp as a good example. >=20 > &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. That's just what I said. In Common Lisp there is no confusion between a keyword parameter and a non-keyword parameter whose argument value is a keyword. No confusion in the spec and no confusion (that I've seen) in use (i.e., users). > > 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). >=20 > 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" You are nitpicking, and it's not pertinent to the discussion. But you are correct in pointing this out. Emacs Lisp has no keyword package (it has no packages), and it has no exact equivalent of Common Lisp keywords. But this is not particularly relevant here (Subject: `What does ":noerror" do?'). Yes, I should have said "whose name is immediately preceded by a colon", or some such, instead of "whose name starts with a colon". And to be very precise I would have needed to write a bit more or even quote from the standard. But it's not the point. The point I made here was to repeat that a keyword is a symbol that evaluates to itself. And that in Common Lisp, too, keywords are sometimes used for just that purpose: as a constant symbol. Keyword parameters are one special use of Common Lisp keywords - and they are=20 irrelevant here. > > 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. >=20 > Yes. And notably, it's considered a design error to mix &optional > with &key or &rest. "It's considered." I guess you mean that you consider it a flaw in the design of Common Lisp. > There are only two functions in CL that do, and only for historical > and legacy compatibility reasons. There might be only two *predefined* Common Lisp functions that do so. But this feature was consciously and deliberately made part of the=20 language. And as a result there are now certainly *lots* of functions that do so. The "flawed" designers were very careful about how they specified this feature, the relation between &key and &rest etc. They did it on purpose. But again, this is not pertinent. The point was that (a) there is no need to know about Common Lisp keyword parameters when using Emacs Lisp and reading its doc, and (b) even for Common Lisp users there is no such confusion as you introduced, between keyword parameters and other uses of keywords. It's a non-problem, and is anyway irrelevant to the OP's question. > > 1. This is Emacs Lisp, which has no keyword parameters (no > > `&key'). >=20 > It has, with (require 'cl) (defun* =E2=80=A6). In that case, see the Emacs Lisp doc for library CL. You will find there _zero_ specification/description/explanation of any of this. The Emacs doc simply refers you to the Common Lisp doc. E.g., for `defun*': Like normal `defun', except ARGLIST allows full Common Lisp conventions, and BODY is implicitly surrounded by (cl-block NAME ...) Stick to the topic, please. There is nothing in the problem as stated that justifies bringing in Common-Lisp keyword parameters and thus adding more confusion. The question was about Emacs-Lisp function `load' and its use in `(load "emacspeak-loader" :noerror)', which was from this post: http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00256.html I see nothing there about using cl.el. It is true that that code was in turn for installing EmacsSpeak, which itself uses cl.el. However, grepping the EmacsSpeak sources indicates that they too apparently make no use of `&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'. >=20 > 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. Irrelevant to the OP example posed. You introduced extraneous possible confusion - a bogeyman "TERROR". The confusion in the OP question was about using a keyword as a constant argument value. The OP understood that this was just a constant that is equivalent, as a Boolean value, to passing a quoted symbol `'NOERROR'. He was asking whether he might be missing something, because he "could't find this kind of usage in lispref." We clarified "this kind of usage" (i.e., confirmed that he in fact understood correctly). We probably should have also pointed him to (elisp)`Constant Variables', but it seemed like he was already pretty clear about it. The point is that he was not asking about Common Lisp (or cl.el) keyword parameters. His question was whether using `:noerror' here was perhaps something special, somehow essentially different from just using `'NOERROR' or `t'. He apparently already thought not, but wanted to be sure he wasn't missing something. And he wasn't. He certainly wasn't missing, and didn't need, additional possible confusion wrt Common Lisp keyword parameters. =20 > > 4. Since there are NO keyword parameters in Emacs Lisp, bringing > > them into this discussion creates, instead of removes, confusion. >=20 > Extends the horizons and propose a would be welcome evolution. Off-topic and confusing, IMO. If you want to propose adding keyword parameters to Emacs Lisp, a new thread is the right place to do that, and preferably in emacs-devel@gnu.org. FWIW, I, for one, am favorable to the idea. And I believe that RMS is still opposed. Whether the current maintainer would be in favor, and if so whether someone would volunteer to implement it, remain to be seen. > > A keyword passed to an Emacs Lisp function NEVER introduces a > > keyword-parameter value. >=20 > 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. Yes. That is the point. Good use of names can lead; bad use can mislead. =20 > > 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). >=20 > That may give a hint to the reader, but can still mislead in case of > error. Yes, if a writer uses names badly s?he can mislead instead of lead readers. We generally do our best to help. In my case, I add such reminders first of all for myself: the writer is also a reader. It is much quicker (for me) to read something with such a reminder than it is to hit `C-h f' and remind myself of a function signature that way. (I turn off `eldoc-mode' most of the time.) And if I mislead myself (it can happen) by misnaming or mistyping then, well, I mislead myself - until I fix it. I will add an obvious point: such named Boolean arguments are more useful when there are many possible arguments, some of which are Boolean, some of which are optional, and some of which are not used often. It is particularly in such cases that I tend to start naming Boolean arguments, to keep things straight when I read. This is really no different from using a comment. If the particular non-nil value makes no difference, then giving it a name serves only as commentary/doc. Commentary & doc can be good or bad. The possibility of bad help is not a reason not to help.