to...@tuxteam.de writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sat, Nov 07, 2015 at 01:58:48PM +0100, Atticus wrote: >> So I wanted to try out gnu guix and thus make myself more familiar with >> guile first. While running some tests I encountered a problem/bug with eq?: >> >> $ guile -v >> guile (GNU Guile) 2.1.1 >> >> $ guile >> scheme@(guile-user)> >> (define (multirember a lat) >> (cond >> ((null? lat) '()) >> ((eq? (car lat) a) (multirember a (cdr lat))) >> (else (cons (car lat) (multirember a (cdr lat)))))) >> >> scheme@(guile-user)> (multirember '(a b) '(x y (a b) z (a b))) >> $1 = (x y z) >> >> So why does guile return (x y z)? I expected (x y (a b) z (a b)). I know >> eq? should only be used with symbols (and thus this example is more >> theoretical) but nevertheless the return value is not right, since (eq? >> '(a b) '(a b)) returns #f (Btw same in guile 2.0.11). > > Hm. As far as I know (eq? '(a b) '(a b)) is not *guaranteed* to evaluate > to #f. The implementation might be free to re-use things it "knows" to be > constant (I might be wrong, though).
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. 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. 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? Btw sorry for the bad bug report, I shoud have read the documentation (didn't include the necessary pseudo-headers)
