* bug#7145: elisp-code behaves differently after byte-compilation
@ 2010-10-02 1:53 Markus Sauermann
2010-10-02 8:54 ` Andreas Schwab
0 siblings, 1 reply; 5+ messages in thread
From: Markus Sauermann @ 2010-10-02 1:53 UTC (permalink / raw)
To: 7145
Hi,
I understand that byte-compiled code should do the same as the
uncompiled code (besides the macro-expansion problematic)
The following code however shows a case where this is not the case.
--- BEGIN CODE ---
(let ((fun (lambda () (let ((bar "foo")
(baz "foo"))
(eq bar baz)))))
(list (funcall (byte-compile fun))
(funcall fun)))
--- END CODE---
Evaluation this code (don't try to byte-compile it, because it is buggy ;-) ) results in:
--- BEGIN OUTPUT ---
(t nil)
--- END OUTPUT ---
which clearly means the byte compiation is somewhat broken. It seems
during compilation the two strings "foo" are treated as the same
string.
Regards
Markus
--
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#7145: elisp-code behaves differently after byte-compilation
2010-10-02 1:53 bug#7145: elisp-code behaves differently after byte-compilation Markus Sauermann
@ 2010-10-02 8:54 ` Andreas Schwab
2010-10-02 10:41 ` Johan Bockgård
0 siblings, 1 reply; 5+ messages in thread
From: Andreas Schwab @ 2010-10-02 8:54 UTC (permalink / raw)
To: Markus Sauermann; +Cc: 7145
"Markus Sauermann" <mhoram@gmx.de> writes:
> The following code however shows a case where this is not the case.
>
> --- BEGIN CODE ---
> (let ((fun (lambda () (let ((bar "foo")
> (baz "foo"))
> (eq bar baz)))))
> (list (funcall (byte-compile fun))
> (funcall fun)))
> --- END CODE---
>
> Evaluation this code (don't try to byte-compile it, because it is buggy ;-) ) results in:
>
> --- BEGIN OUTPUT ---
> (t nil)
> --- END OUTPUT ---
This is not a bug. You cannot depend on the uniqueness of literal
strings. If you want to compare strings you should use equal.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#7145: elisp-code behaves differently after byte-compilation
2010-10-02 8:54 ` Andreas Schwab
@ 2010-10-02 10:41 ` Johan Bockgård
2010-10-03 5:12 ` Chong Yidong
0 siblings, 1 reply; 5+ messages in thread
From: Johan Bockgård @ 2010-10-02 10:41 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Markus Sauermann, 7145
Andreas Schwab <schwab@linux-m68k.org> writes:
> "Markus Sauermann" <mhoram@gmx.de> writes:
>
>> The following code however shows a case where this is not the case.
>>
>> --- BEGIN CODE ---
>> (let ((fun (lambda () (let ((bar "foo")
>> (baz "foo"))
>> (eq bar baz)))))
>> (list (funcall (byte-compile fun))
>> (funcall fun)))
>> --- END CODE---
>>
>> Evaluation this code (don't try to byte-compile it, because it is buggy ;-) ) results in:
>>
>> --- BEGIN OUTPUT ---
>> (t nil)
>> --- END OUTPUT ---
>
> This is not a bug.
But this is, IMO:
(progn
(defsubst spooky-action-at-a-distance ()
(let ((a (concat "a" "bc")))
(store-substring a 0 "123")))
(defun foo ()
(spooky-action-at-a-distance)
(concat "ab" "c"))
(byte-compile 'foo)
(foo))
=> "123"
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#7145: elisp-code behaves differently after byte-compilation
2010-10-02 10:41 ` Johan Bockgård
@ 2010-10-03 5:12 ` Chong Yidong
2010-10-05 17:37 ` Markus Sauermann
0 siblings, 1 reply; 5+ messages in thread
From: Chong Yidong @ 2010-10-03 5:12 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Markus Sauermann, 7145
Johan Bockgård <bojohan@gnu.org> writes:
> But this is, IMO:
>
> (progn
> (defsubst spooky-action-at-a-distance ()
> (let ((a (concat "a" "bc")))
> (store-substring a 0 "123")))
>
> (defun foo ()
> (spooky-action-at-a-distance)
> (concat "ab" "c"))
>
> (byte-compile 'foo)
> (foo))
>
> => "123"
I think we're just going to have to ask people not to do that...
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#7145: elisp-code behaves differently after byte-compilation
2010-10-03 5:12 ` Chong Yidong
@ 2010-10-05 17:37 ` Markus Sauermann
0 siblings, 0 replies; 5+ messages in thread
From: Markus Sauermann @ 2010-10-05 17:37 UTC (permalink / raw)
To: Chong Yidong; +Cc: 7145, Andreas Schwab
Hi,
Am 03.10.2010 07:12, schrieb Chong Yidong:
>
> I think we're just going to have to ask people not to do that...
>
it looks like an undocumented feature ;-)
Here is a suggestion for a patch for the documentation (trunk of emacs
Bazaar repository)
--- BEGIN ---
=== modified file 'doc/lispref/objects.texi'
--- doc/lispref/objects.texi 2010-08-19 23:23:13 +0000
+++ doc/lispref/objects.texi 2010-10-05 18:00:58 +0000
@@ -1999,6 +1999,17 @@
@result{} nil
@end group
@end example
+
+Be aware that byte-compiling a comparison of strings with @code{eq}
+might give unexpected results.
+
+@example
+@group
+(funcall (byte-compile (lambda () (let ((foo "bar"))
+ (eq foo "bar")))))
+ @result{} t
+@end group
+@end example
@end defun
@defun equal object1 object2
--- END ---
Regards
Markus
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-10-05 17:37 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-02 1:53 bug#7145: elisp-code behaves differently after byte-compilation Markus Sauermann
2010-10-02 8:54 ` Andreas Schwab
2010-10-02 10:41 ` Johan Bockgård
2010-10-03 5:12 ` Chong Yidong
2010-10-05 17:37 ` Markus Sauermann
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).