bug#20241: 25.0.50; `setq' with only one argument

[Drew Adams]

> 1. Interpreter:
>   (a) Current behviour: silently insert a nil into the `setq'.
>   (b) Throw an error (current new behaviour in emacs-25).
>   (c) Issue a warning, but continue otherwise with (a).

1b is what I prefer.

> 2. Compiler:
>   (a) Silently compile code which slips in a nil (current behaviour).
>   (b) Issue a warning, but compile in the nil.
>   (c) Issue an error, but compile in the nil.  (current new behaviour
>     in emacs-25.)
>   (d) Issue an error, and abort the compilation:
>     (i) immediately.
>     (ii) at the end of the source file.
>   (e) Issue an error, and generate code to:
>      (i) issue a warning, but carry on with the nil.
>      (ii) throw an error.

Code that applies `setq' to an odd number of args is erroneous
syntactically.  The compiler can point out that syntax error.

And it need not (and should not) abort the compilation just
because it reports that syntax error - it can continue to
report other problems.

Or if by "abort" you mean just not produce compiled output (but
continue to analyze the code and report as many problems as
possible), I don't think that is necessary (or good) either,
in this case (provided that the resulting code raises a runtime
error.)

> You seem to favour 1(b) and, I think, 2(d)(ii) or 2(e)(ii).
> I favour 1(b) and probably 2(c), possibly 2(e)(i).

My preference for the compiler is to (a) let you know there
are syntax problems, and where they are, and (b) generate code
that acts the same as the interpreted code: in this case,
raise a runtime error.

> To me, these possibilities are complicated.  It's not a
> technical problem, it's a social problem: who's going to be
> notified of the problem and when.  I would far rather
> maintainers were hassled than users.

As long as the code is erroneous, users should get an error
from it.  If you can fix the code then they won't get an
error.  If you cannot fix it now, then they should get an
error.  If it's important enough that they not get the error
then it's important enough that the code should be fixed
(e.g., before the release).

Anyway, I'm no doubt repeating myself now.  At least you
know now what I prefer for the behavior, including for the
compiler.  FWIW.

And thanks for working on this.