RE: What does ":noerror" do?

[Drew Adams <drew.adams@oracle.com>]

> 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.

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.
> 
> &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).
> 
> 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 
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.
> 
> 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 
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').
> 
> It has, with (require 'cl) (defun* …).

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'.
> 
> 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.
 
> > 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.

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.
> 
> 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.
 
> > 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.

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.