bug#21855: eq?

bug#21855: eq?

[Atticus]

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).

bug#21855: eq?

[tomas]

-----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).

Regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlY/IpsACgkQBcgs9XrR2kZMoACZAc49Kzq9JzteJovmzRpH2WLv
M3YAnibf8NUd5bspCqCP2cQiAWNSiREt
=O1dE
-----END PGP SIGNATURE-----

bug#21855: eq?

[Atticus]

tomas@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-user@gnu.org would be better. What is the
recommended proceeding in such a case? A reply with the pseudo-header
"X-Debbugs-CC: guile-user@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)

bug#21855: eq?

[tomas]

-----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-user@gnu.org would be better. What is the
> recommended proceeding in such a case? A reply with the pseudo-header
> "X-Debbugs-CC: guile-user@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.

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>

regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlY/UFsACgkQBcgs9XrR2kaLQwCeKByrAN8ODfbCkIqRt8RMEpNL
9fcAmwTvngBuJ4qSlybyu/miPX8LROiS
=or0E
-----END PGP SIGNATURE-----

bug#21855: eq?

[Atticus]

tomas@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-user@gnu.org would be better. What is the
>> recommended proceeding in such a case? A reply with the pseudo-header
>> "X-Debbugs-CC: guile-user@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.

bug#21855: eq?

[Andy Wingo]

On Sun 08 Nov 2015 11:23, <tomas@tuxteam.de> writes:

> 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).

Tomas is correct; within one compilation unit, constant literals will be
deduplicated.  That means that within one compilation unit, (eq? '(a b)
'(a b)) will indeed be #t.... yarggghhhh.... but:

  scheme@(guile-user)> (eq? '(a b) '(a b))
  $1 = #f
  scheme@(guile-user)> ,optimize (eq? '(a b) '(a b))
  $2 = #f

Evidently the optimizer is doing the compare at compile-time, which it
is allowed to do, and at compile-time the values are actually distinct.
I will see if I can fix that.  However Tomas' logic is impeccable :)

Closing as things are all working fine, I think.

Cheers,

Andy