Re: What does ":noerror" do?

[Pascal J. Bourguignon]

Drew Adams <drew.adams@oracle.com> 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/