[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#20241: 25.0.50; `setq' with only one argument
From: |
Drew Adams |
Subject: |
bug#20241: 25.0.50; `setq' with only one argument |
Date: |
Wed, 25 Nov 2015 11:22:31 -0800 (PST) |
> > 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.
>
> Let's take a different case as a behavorial example: The code: (funcall)
> Interpreted: Raises an error: eval: Wrong number of arguments:
> funcall, 0
> Byte-compilation: No warnings or errors printed.
> Loading of .elc: Raises an error: load: Wrong number of arguments:
> funcall, 0
>
> I think that we should be consistent in our behavior. Mis-using Emacs Lisp
> is not a reason to fail to byte-compile, even if it is a reason for it to
> fail to evaluate or load.
>
> A separate argument could be made that bad code shouldn't compile, but
> that's orthogonal to this discussion, and too big a pill to swallow for
> 25.1.
I think we are agreeing, unless I'm missing something (?).
In the case of `funcall', which is a function, the byte-compiler
could conceivably, in some cases, point out a syntax error that
a missing FUNCTION arg is required for `funcall'.
It could not point that out in all cases. For example:
(apply #'funcall (some-sexp)), might end up applying `funcall' to
(). But in many cases it could find syntax errors of this kind.
`setq' is not a function (you cannot pass `setq' to `apply'), so
it is generally easier to check its syntax.
Whatever problems the byte-compiler finds and reports are welcome,
but the mere fact of reporting problems does not obviate the need
for runtime errors when incorrect syntax is used.
And certainly byte-compilation should not try to "correct" code
(any more than the interpreter should) by, for example, implicitly
providing a nil arg for `setq'. That's just plain wrong, IMO.
- bug#20241: 25.0.50; `setq' with only one argument, (continued)
- bug#20241: 25.0.50; `setq' with only one argument, Drew Adams, 2015/11/25
- bug#20241: 25.0.50; `setq' with only one argument, Alan Mackenzie, 2015/11/25
- bug#20241: 25.0.50; `setq' with only one argument, Drew Adams, 2015/11/25
- bug#20241: 25.0.50; `setq' with only one argument, Alan Mackenzie, 2015/11/25
- bug#20241: 25.0.50; `setq' with only one argument, Drew Adams, 2015/11/25
- bug#20241: 25.0.50; `setq' with only one argument, John Wiegley, 2015/11/25
- bug#20241: 25.0.50; `setq' with only one argument,
Drew Adams <=
- bug#20241: 25.0.50; `setq' with only one argument, Artur Malabarba, 2015/11/25
- bug#20241: 25.0.50; `setq' with only one argument, John Wiegley, 2015/11/25
- bug#20241: 25.0.50; `setq' with only one argument, Artur Malabarba, 2015/11/25
- bug#20241: 25.0.50; `setq' with only one argument, John Wiegley, 2015/11/25
- bug#20241: 25.0.50; `setq' with only one argument, Alan Mackenzie, 2015/11/26
- bug#20241: 25.0.50; `setq' with only one argument, Alan Mackenzie, 2015/11/25
- bug#20241: 25.0.50; `setq' with only one argument, Drew Adams, 2015/11/25
- bug#20241: 25.0.50; `setq' with only one argument, John Wiegley, 2015/11/25
- bug#20241: 25.0.50; `setq' with only one argument, John Mastro, 2015/11/25
- bug#20241: 25.0.50; `setq' with only one argument, Johan Bockgård, 2015/11/25