* [Bug] (defun foo) during compilation defines `foo' as 0-arg `igno re'
@ 2003-04-07 17:27 Wedler, Christoph
2003-04-07 19:55 ` Kai Großjohann
0 siblings, 1 reply; 3+ messages in thread
From: Wedler, Christoph @ 2003-04-07 17:27 UTC (permalink / raw)
[Test using Emacs-21.2.95.1.]
If you evaluate (defun foo), you get the error
(wrong-number-of-arguments #<subr defun> 1)
If you like to have your .el files compiled without warnings, you might
want to use above form just like you could use (defvar foo). OK, let's
write the file bar.el:
(eval-when-compile
(defun foo))
(defun bar ()
(if (fboundp 'foo) (foo)) ; or more complicated
(message "bar"))
Using M-x byte-compile-file RET bar.el RET now doesn't produce any
warnings. At first, you think, "hey, this is great", but then you
realize, it's not so:
1. If you call (foo 2) instead (foo), you get the warning
While compiling bar:
** foo called with 1 argument, but accepts only 0
2. After the compilation, evaluating (fboundp 'foo) returns t, and
`foo' is defined as a 0-arg function which returns nil.
While 1 is just annoying, 2 is really bad: if a package uses (defun
foo), it must now mention in INSTALL s/th like "exit and restart Emacs
after any compilation of the .el files". If (defun foo) would simply
signal an error, we could use (ignore-errors (defun foo)) in the hope
that a future Emacs would define a useful semantics for (defun foo),
i.e., just like for (defvar foo).
- Christoph
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bug] (defun foo) during compilation defines `foo' as 0-arg `igno re'
2003-04-07 17:27 [Bug] (defun foo) during compilation defines `foo' as 0-arg `igno re' Wedler, Christoph
@ 2003-04-07 19:55 ` Kai Großjohann
0 siblings, 0 replies; 3+ messages in thread
From: Kai Großjohann @ 2003-04-07 19:55 UTC (permalink / raw)
"Wedler, Christoph" <christoph.wedler@sap.com> writes:
> [Test using Emacs-21.2.95.1.]
>
> If you evaluate (defun foo), you get the error
> (wrong-number-of-arguments #<subr defun> 1)
There has been talk about making (defun foo) behave analogously to
(defvar foo), but at the moment this is not so, AFAIK.
You can require the package where foo is defined.
In Tramp, I have the problem with compatibility code, and there I
fool the Lisp interpreter by doing (funcall 'foo ...), but that's
probably not the right approach.
--
A preposition is not a good thing to end a sentence with.
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: [Bug] (defun foo) during compilation defines `foo' as 0-arg ` igno re'
@ 2003-04-08 17:57 Wedler, Christoph
0 siblings, 0 replies; 3+ messages in thread
From: Wedler, Christoph @ 2003-04-08 17:57 UTC (permalink / raw)
>> If you evaluate (defun foo), you get the error
>> (wrong-number-of-arguments #<subr defun> 1)
> There has been talk about making (defun foo) behave analogously to
> (defvar foo), but at the moment this is not so, AFAIK.
Hm, maybe my message was a bit unclear. The point of my bug report
(otherwise, it would be a feature request) was that (defun foo) does NOT
SIGNAL an ERROR when used inside `eval-when-compile'.
> You can require the package where foo is defined.
Then it would be as bad as (defun foo) inside `eval-when-compile'...
> In Tramp, I have the problem with compatibility code, and there I
> fool the Lisp interpreter by doing (funcall 'foo ...), but that's
> probably not the right approach.
At least the XEmacs byte compile would still warn about `foo' not being
defined...
- Christoph
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-04-08 17:57 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-04-08 17:57 [Bug] (defun foo) during compilation defines `foo' as 0-arg ` igno re' Wedler, Christoph
-- strict thread matches above, loose matches on Subject: below --
2003-04-07 17:27 [Bug] (defun foo) during compilation defines `foo' as 0-arg `igno re' Wedler, Christoph
2003-04-07 19:55 ` Kai Großjohann
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).