From: Ikumi Keita <ikumi@ikumi.que.jp>
To: Robert Cochran <robert-emacs@cochranmail.com>
Cc: Andreas Schwab <schwab@suse.de>,
31718@debbugs.gnu.org, Vibhav Pant <vibhavp@gmail.com>
Subject: bug#31718: 26.1; Strange behavior of `cond'
Date: Wed, 06 Jun 2018 18:14:03 +0900 [thread overview]
Message-ID: <48698.1528276443@localhost> (raw)
In-Reply-To: <87wovc8ipt.fsf@cochranmail.com>
Hi Robert,
>>>>> Robert Cochran <robert-emacs@cochranmail.com> writes:
> Ikumi Keita <ikumi@ikumi.que.jp> writes:
>> Hi Andreas, thanks for your reply.
>>
>>>>>>> Andreas Schwab <schwab@suse.de> writes:
>>> On Jun 05 2018, Ikumi Keita <ikumi@ikumi.que.jp> wrote:
>>>> (defun xyz (arg)
>>>> "dummy"
>>>> ; (cond ((eq arg nil) ; OK
>>>> ; (cond ((eq arg 'abc) ; OK
>>>> ; (cond ((eq arg 'def) ; OK
>>>> (cond ((eq arg 'default) ; NG
>>
>>> The byte-compiler uses 'default as a magic symbol, which breaks this
>>> case.
>>
>> Does this mean that this behavior is a (new) designed feature of elisp
>> and not a bug?
>> If so, is it the respoisibility of the authors of the codes to rewrite
>> not to use `default' or else to make sure to set
>> `byte-compile-cond-use-jump-table' to nil at byte compile?
> I for one consider this a bug, for 2 reasons:
> 1) It's not reasonable to expect a Lisp programmer to just know that
> using the symbol default is problematic.
> 2) It creates diverging behavior between compiled and non-compiled Lisp.
I agree.
> To that end, I've made a small patch to rectify the behavior. Instead of
> hardcoding a symbol, it uses gensym to create a unique one. I did a full
> build of Emacs, as well as ran 'make check' and had identical results
> pre- and post-change, so I'm reasonably sure it's correct.
Thanks for the patch, it fixes the problem on my side!
Regards,
Ikumi Keita
next prev parent reply other threads:[~2018-06-06 9:14 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-05 6:26 bug#31718: 26.1; Strange behavior of `cond' Ikumi Keita
2018-06-05 8:07 ` Andreas Schwab
2018-06-06 5:41 ` Ikumi Keita
2018-06-06 7:41 ` Robert Cochran
2018-06-06 9:14 ` Ikumi Keita [this message]
2018-06-12 1:34 ` Robert Cochran
2018-06-12 22:22 ` Noam Postavsky
2018-06-13 5:51 ` Ikumi Keita
2018-06-13 6:26 ` Vibhav Pant
2018-06-16 15:10 ` Paul Eggert
2018-06-16 15:20 ` Eli Zaretskii
2018-06-16 15:28 ` Paul Eggert
2018-06-16 16:02 ` Eli Zaretskii
2018-06-16 16:45 ` Paul Eggert
2018-06-16 15:23 ` Noam Postavsky
2018-06-16 15:30 ` Paul Eggert
2018-06-16 23:00 ` Drew Adams
2018-06-17 4:44 ` Michael Heerdegen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48698.1528276443@localhost \
--to=ikumi@ikumi.que.jp \
--cc=31718@debbugs.gnu.org \
--cc=robert-emacs@cochranmail.com \
--cc=schwab@suse.de \
--cc=vibhavp@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).