GNU bug report logs - #20241
25.0.50; `setq' with only one argument

Previous Next

Full log

Message #76 received at 20241 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: John Wiegley <jwiegley <at> gmail.com>, 20241 <at> debbugs.gnu.org,
 Artur Malabarba <bruce.connor.am <at> gmail.com>
Subject: RE: bug#20241: 25.0.50; `setq' with only one argument
Date: Wed, 25 Nov 2015 10:28:11 -0800 (PST)

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.