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.



Reply via email to