RE: What does ":noerror" do?

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

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

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.