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

[Alan Mackenzie]

Hello, Drew.

On Wed, Nov 25, 2015 at 08:27:43AM -0800, Drew Adams wrote:

[ .... ]

> But if you can DTRT now - analyze the code sufficiently and fix
> it properly or contact the author for an opinion - then that's
> the thing to do.

That's already been done with the Emacs core, and that's what I'd like
to do with elpa.  But code over which we have no control might be
problematic.

> Or if you just leave the code as is, but ensure that a runtime
> error is raised, that is also TRT.  It takes care of THIS bug,
> but it does not fix that bug (indicated by the error occurrence).

That would mean the users will suffer an error rather than the
maintainers.  And the Emacs team will get blamed for the breakage.

[ .... ]

> > > IMO, the bug should be fixed to raise an _error at runtime_,
> > > for both interpreted and byte-compiled code.

I think that a compiler generating a runtime error for a compile time
problem isn't a good idea.

[ .... ]

> The byte-compiler is not just some QA tool to check whether i's
> are dotted and t's are crossed.

No, but that is a significant part of its job spec.

[ .... ]

> > Why is this topic suddenly seeming complicated?  :-(

> I don't think it's complicated.  `setq' should raise an error
> when it is passed an odd number of arguments.  _That's all._
> The error should be raised when `setq' is invoked, obviously.

There are several different behaviours possible in both the interpreter
and compiler:

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

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.

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

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).