bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#24913: 25.1.50; Emacs accepts undocumented and confusing combination


From: Philipp Stephani
Subject: bug#24913: 25.1.50; Emacs accepts undocumented and confusing combinations of &optional and &rest in argument lists
Date: Sun, 20 Nov 2016 12:41:02 +0000



Gemini Lasswell <gazally@runbox.com> schrieb am So., 20. Nov. 2016 um 07:31 Uhr:
Philipp Stephani <p.stephani2@gmail.com> writes:

>  A more general solution would be to have the byte compiler try to match
>  Edebug specs, and issue a warning or an error if it fails. That would
>  help find errors in the invocations of all macros, not just ones with
>  argument lists.
>
> I don't understand how this is related. This is only about function
> definitions in the evaluator and the byte compiler. I don't see how
> Edebug could help here.

Edebug specs describe the expected syntax for the arguments of a macro,
including the macros which define functions, such as lambda, defun,
defmacro etc. If Edebug can't match the actual arguments in a macro
invocation to the Edebug spec for that macro, it will signal an error.
For an example of Edebug catching a misplaced &optional in an argument
list, see bug#24762.

So part of my suggestion is that since there exists in Emacs a powerful
mechanism for checking macro argument lists, it would be better to use
it if we want to let programmers know that their macro invocations are
incorrect, instead of adding error checking to individual macros on a
case by case basis.

Another thought going into this suggestion is my observation that it's
not difficult to find bugs in Edebug specs in the Emacs sources right
now. One cause of that could be the Edebug spec documentation, which
could be improved. But I think the primary reason is that a macro with a
broken Edebug spec won't cause an error until someone tries to use
Edebug or Testcover on an invocation of that macro, which maybe isn't
common practice when reviewing changes. But if the byte compiler checked
Edebug specs and signaled errors, then at least those errors in Edebug
specs which can be found statically would be noticed immediately.

Integrating Edebug checks, byte-compiler checks, and evaluator checks sounds like the right thing to do, but also like a huge amount of work that is out of scope for this bug. Please create a new bug if you want that.
Note that a generic checker would still need to catch cases such as
(funcall (function (lambda (&rest))) ())
that don't involve any macros. 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]