unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Atticus <atticus0@posteo.org>
To: tomas@tuxteam.de
Cc: 21855@debbugs.gnu.org
Subject: bug#21855: eq?
Date: Mon, 09 Nov 2015 08:57:59 +0100	[thread overview]
Message-ID: <87si4fvc3c.fsf@posteo.org> (raw)
In-Reply-To: <20151108133835.GA11324@tuxteam.de>

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.





  reply	other threads:[~2015-11-09  7:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-07 12:58 bug#21855: eq? Atticus
2015-11-08 10:23 ` tomas
2015-11-08 13:30   ` Atticus
2015-11-08 13:38     ` tomas
2015-11-09  7:57       ` Atticus [this message]
2016-06-24 15:31   ` Andy Wingo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87si4fvc3c.fsf@posteo.org \
    --to=atticus0@posteo.org \
    --cc=21855@debbugs.gnu.org \
    --cc=tomas@tuxteam.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).