to...@tuxteam.de writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sun, Nov 08, 2015 at 02:30:42PM +0100, Atticus wrote: > > [...] > >> Yes you are right that the implementation may treat it as non #f if both >> arguments refer to the same object. In r5rs (and also r6rs) (eq? '(a) >> '(a)) is unspecified (r5rs, page 19) and thus implementation dependant >> but I don't think the behaviour of eq? is consistent in guile. > > My hunch is that it *can't* be consistent (see below) > >> As I said >> (eq? '(a b) '(a b)) on its own returns #f and imho there is no reason why eq? >> inside a procedure (in this example in 'multirember') should behave >> different, since the '(a b) in the second argument does not refer to the >> '(a b) of the first argument. > > Modulo vagaries of the optimizer :-)
:-) >> Since it's not clear if this is a "real" bug, perhaps a further >> discussion at guile-u...@gnu.org would be better. What is the >> recommended proceeding in such a case? A reply with the pseudo-header >> "X-Debbugs-CC: guile-u...@gnu.org"? Or is that not necessary and a >> simple mail to guile-user to discuss this topic is sufficient? > > Note that I'm not authoritative in this questions, so you'll have to > wait on someone with more knowledge than me for a more definiteve answer. Ok. > But as far as I can gather, those things can get caught in a common > subexpression elimination[1] step, and the results will depend on the > current optimization strategies. That's why r5rs is vague about that. > They (rightfully) don't want to shut off those (in some cases vital) > optimizations. > > The take away (for me, at least) is "use eq? just for symbols", at > least unless you know what you are doing. > > [1] > <https://wingolog.org/archives/2014/08/25/revisiting-common-subexpression-elimination-in-guile> Thanks for the link; an interesting read.