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

[Alan Mackenzie]

Hello, Drew.

On Wed, Nov 25, 2015 at 07:18:17AM -0800, Drew Adams wrote:
> > If you found four occurrences merely by grepping, there could well be
> > quite a few more.  In the last one, for example, can we be sure that nil
> > is intended, not that the real argument has just been missed out?

> If you cannot now analyze the code properly to determine TRT, or
> contact the author to make that determination, then do the obvious
> (IMO): Assign a `nil' value explicitly where it is now assigned
> implicitly.

That would be the worst thing: it would leave the code possibly failing
exactly the way it did, but remove the evidence (which can be
mechanically found).

> AND flag that amended code with a comment saying what you've done,
> and that you don't currently know whether (a) there is a bug here
> or (b) `nil' is really what is needed.

Comments are less good than error messages from the byte compiler!

> IOW: (1) At least just ensure that the code does the same thing
> that it does now, but respects the intended meaning of `setq'.
> (2) If you have to punt the careful analysis for later or for
> someone else, then add a comment to that effect.

> > Maybe having the byte compiler error out in this situation isn't such a
> > brilliant idea after all.

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

I've just tried it out.  The byte compiler generates an error message,
but the .elc is written anyway.  No runtime error happens from such
compiled code.  But running it interpreted would signal an error.

> Whatever else the byte-compiler might do is less important, as
> long as it produces code that is comparable - e.g., code that
> will also raise an _error at runtime_.

It currently doesn't do that.  I'm not convinced it should, either.

> It's OK for a byte-compiler to be smart, but not smarter than
> the actual source code ;-).  It should pretty much try to
> produce code that does the same thing, but hopefully usually
> does it quicker.

Why is this topic suddenly seeming complicated?  :-(

-- 
Alan Mackenzie (Nuremberg, Germany).