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

[Drew Adams <drew.adams@oracle.com>]

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