From: Drew Adams <drew.adams@oracle.com>
To: Alan Mackenzie <acm@muc.de>
Cc: John Wiegley <jwiegley@gmail.com>,
20241@debbugs.gnu.org,
Artur Malabarba <bruce.connor.am@gmail.com>
Subject: bug#20241: 25.0.50; `setq' with only one argument
Date: Wed, 25 Nov 2015 10:28:11 -0800 (PST) [thread overview]
Message-ID: <5c5c14de-444e-4847-b91a-e7dff29b3f58@default> (raw)
In-Reply-To: <20151125172211.GH2007@acm.fritz.box>
> 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.
next prev parent reply other threads:[~2015-11-25 18:28 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-01 14:53 bug#20241: 25.0.50; `setq' with only one argument Drew Adams
2015-04-01 16:41 ` Stefan Monnier
[not found] ` <mailman.3138.1427900048.31049.bug-gnu-emacs@gnu.org>
2015-11-23 14:31 ` Alan Mackenzie
2015-11-23 18:44 ` Glenn Morris
2015-11-23 18:54 ` Glenn Morris
2015-11-23 22:05 ` John Wiegley
2015-11-23 19:31 ` Alan Mackenzie
2015-11-24 11:32 ` Alan Mackenzie
2015-11-24 17:38 ` Glenn Morris
2015-11-24 18:04 ` Alan Mackenzie
2015-11-24 19:26 ` Artur Malabarba
2015-11-24 21:09 ` Alan Mackenzie
2015-11-25 1:46 ` John Wiegley
2015-11-25 9:41 ` Alan Mackenzie
2015-11-25 10:36 ` Artur Malabarba
2015-11-25 11:07 ` Alan Mackenzie
2015-11-25 11:13 ` Artur Malabarba
2015-11-25 11:28 ` Alan Mackenzie
2015-11-25 15:18 ` Drew Adams
2015-11-25 15:40 ` Alan Mackenzie
2015-11-25 16:27 ` Drew Adams
2015-11-25 17:22 ` Alan Mackenzie
2015-11-25 18:28 ` Drew Adams [this message]
2015-11-25 19:06 ` John Wiegley
2015-11-25 19:21 ` John Mastro
2015-11-25 19:22 ` Drew Adams
2015-11-25 19:34 ` Artur Malabarba
2015-11-25 19:40 ` John Wiegley
2015-11-25 20:20 ` Artur Malabarba
2015-11-25 20:37 ` John Wiegley
2015-11-26 11:07 ` Alan Mackenzie
2015-11-25 20:58 ` Alan Mackenzie
2015-11-25 21:19 ` Drew Adams
2015-11-25 21:52 ` John Wiegley
2015-11-26 0:21 ` Johan Bockgård
2015-11-26 8:58 ` Andreas Schwab
2015-11-26 12:06 ` Alan Mackenzie
2015-11-26 16:38 ` Artur Malabarba
2015-11-26 21:19 ` Alan Mackenzie
2015-11-27 0:07 ` Artur Malabarba
2015-11-25 13:11 ` Nicolas Richard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5c5c14de-444e-4847-b91a-e7dff29b3f58@default \
--to=drew.adams@oracle.com \
--cc=20241@debbugs.gnu.org \
--cc=acm@muc.de \
--cc=bruce.connor.am@gmail.com \
--cc=jwiegley@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.