emacs-devel
[Top][All Lists]
Advanced

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

Re: functionp bug


From: Katsumi Yamaoka
Subject: Re: functionp bug
Date: Wed, 09 Apr 2008 16:56:11 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

>>>>> Reiner Steib wrote:
>> Maybe it is possible to fix them all, but is it really the right thing
>> to make such an incompatible change?  What is the reason for
>> this change?

>>>>> Stefan Monnier wrote:
> That the strange definition of `functionp' was never what was really
> needed: if special-forms should be accepted, than so should macros.

I don't want `functionp' to accept macros because macros cannot
be funcall'd.  I had been using `functionp' in order to mainly
examine whether the object is a function symbol or a lambda form.
For such a usage, there's no problem with the present definition
if only the function that actually does something, e.g. the one
applicable to `gnus-article-x-face-command', is assumed.

OTHO, Gnus used it even to examine whether the Lisp form in which
the first item might be a special form is able to be eval'd.  `if'
and `or' are not functions?  Yes, it's a sound argument and Gnus'
way might have been a wrong approach even though `functionp' was
easy to use.  However, I'm not sure such an incompatible change
sticking to semantics is really necessary.  While programing
ELisp, to consider that whatever is placed right after the open
parenthesis is a function generally causes no problem, if the
form is assumed to be able to be evaluated, doesn't it?  The use
of `functionp' was handy for such a case.  Neither of examining
whether the object is not a special form and examining whether
the object is a special form will probably be done rarely.

If making the change revert is not acceptable, what we have to
do toward the Gnus 5.10.10 release and the No Gnus v 0.8 release
will be:

1. Merge Stefan's changes:

2008-04-07  Stefan Monnier  <address@hidden>

        * mail-source.el (mail-source-value):
        Prefer fboundp to functionp so it works with macros as well.

2008-04-03  Stefan Monnier  <address@hidden>

        * gnus-win.el (gnus-configure-frame, gnus-all-windows-visible-p):
        Fix last change in case the element is not even a symbol.

2008-03-20  Stefan Monnier  <address@hidden>

        * gnus-win.el (gnus-configure-frame, gnus-all-windows-visible-p):
        Prefer fboundp to functionp so it works with macros as well.

   I'm not sure that's all, though.

2. Post a notice to let people who use the Emacs trunk use this
   workaround:

(or (functionp 'if)
    (defadvice functionp (around workaround-bug (object) activate)
      "Workaround bug."
      (or ad-do-it
          (setq ad-return-value (and (symbolp object) (fboundp object))))))

   It only conceals the problem, though.

3. Replace all `functionp' with `gmm-functionp' which is the same
   as the one in Emacs 22.2.50.  It only conceals the problem, too.

I vote to 1.

Regards,




reply via email to

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