From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Linus_Bj=C3=B6rnstam?= Newsgroups: gmane.lisp.guile.user Subject: Re: Surprising behavior of eq? Date: Sun, 20 Sep 2020 22:51:35 +0200 Message-ID: <40d06884-73d4-4992-81ce-962bf59ac196@www.fastmail.com> References: <8e1d9874-4659-cca5-03da-c2c0df102c56@posteo.de> Mime-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28429"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Cyrus-JMAP/3.3.0-325-g8593b62-fm-20200916.004-g0f995879-bis Cc: guile-user To: "John Cowan" , "Zelphir Kaltstahl" Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Sun Sep 20 22:52:15 2020 Return-path: Envelope-to: guile-user@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kK6Jj-0007Ji-Nj for guile-user@m.gmane-mx.org; Sun, 20 Sep 2020 22:52:15 +0200 Original-Received: from localhost ([::1]:57422 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kK6Ji-0001pL-JJ for guile-user@m.gmane-mx.org; Sun, 20 Sep 2020 16:52:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51650) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kK6JY-0001pC-3n for guile-user@gnu.org; Sun, 20 Sep 2020 16:52:04 -0400 Original-Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:51089) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kK6JV-0006jo-Pu for guile-user@gnu.org; Sun, 20 Sep 2020 16:52:03 -0400 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 9519E60D; Sun, 20 Sep 2020 16:51:58 -0400 (EDT) Original-Received: from imap1 ([10.202.2.51]) by compute4.internal (MEProxy); Sun, 20 Sep 2020 16:51:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.se; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm1; bh=hK2QV cDk6X1dYdt3nQV/BHAfz0cgEf4wI7XThy6iL9o=; b=mBMDpfAWWIkMc0YfV0m+0 U+m2CoS9ZL9kQyVaRsgXkyM6IKSqkwEWuYETT8TQr8AjCdhC8Sd8GNnw4Czt4NAp bMK+wWXh5lteBQBr2kAwZ4Jml1yNhj6Z0ey4EHXwKlEYL74GaP7zPdODwvy4RoxZ oiM5z5jH8Zyi/V7PI2yxmTI8yf0cWCvY1FtPWrYBEFg0vn7SqaYwDhiEcvgLB29E PY4a8dOJty/2Lpf6NYAhYWEuuiBJKMjbmL2h/NwHTVSYJvLkZ0rTlyC5+KKONt5i 3vuMXaopkOrw4h42OM9So2dCSBBszleQ515NfhI7GuH2UnCvrA/SD9gVwKoKSZjM A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=hK2QVcDk6X1dYdt3nQV/BHAfz0cgEf4wI7XThy6iL 9o=; b=LAx6INWMxfYQEf35tNb+EI40WPHtAeg0ZbV1JMCuJRaUjTOjZLTBvpuoR o0V2YQsfdq97UIRsELelVAHpdRWsTFefXkL0+Pb605VDAbnf2WFgKrzVT8zy8HPW QRxvHYrpOsCkZzSUpyf+1QJkeAA5ofRVkLnK9Slmier6CSNpqLnF2FdjYeOQWDKH YUXXYUhLdyGBycRrvsmG6Xcl8lac+RNinvOzmfERQt/5fwVo8K3sDZEaJkIPfEm+ FqoncNB9VYbqEV4kwf/0sxkQgjjULi9iDpRnPt7xNr7KpAUi+X2gnmLg4J4Aw1BW oUhAdkhpZDlhIgaLNbDrkdGl6qNVw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddtgdduheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpefnihhn uhhspgeujhpnrhhnshhtrghmuceolhhinhhushdrihhnthgvrhhnvghtsehfrghsthhmrg hilhdrshgvqeenucggtffrrghtthgvrhhnpeekleevieevleejffetieeltdelkeevtedu heefheduieffffdttdegjeeihedtjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehlihhnuhhsrdhinhhtvghrnhgvthesfhgrshhtmhgrihhl rdhsvg X-ME-Proxy: Original-Received: by mailuser.nyi.internal (Postfix, from userid 501) id BB2D9C200A5; Sun, 20 Sep 2020 16:51:57 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: Received-SPF: pass client-ip=64.147.123.19; envelope-from=linus.internet@fastmail.se; helo=wout3-smtp.messagingengine.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/20 16:51:59 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.io gmane.lisp.guile.user:16941 Archived-At: Just a quick note on guile: if you are testing equality against literals= guile will optimize to the fastest kind. (equal? b 27) becomes (eq? b 2= 7). This was added by Andy sometime since 3.0, after Aleix discovered th= at match was slower than cond-with-eqv? for chars, and that the differen= ce was huge. I wrote an awful patch, which made Andy barf so he fixed it= properly (no. He was very polite. If he barfed, he didn't mention it). A simple optimization that shaved something like 15% of time spent in js= on->scm in guile-json on one of the files we used for benchmarking. It w= as converted to cond for the benefit of 2.2, though, but it is still a n= ice thing to be able to rely on when writing macros. --=20 Linus Bj=C3=B6rnstam On Sun, 20 Sep 2020, at 19:05, John Cowan wrote: > On Sun, Sep 20, 2020 at 11:37 AM Zelphir Kaltstahl < > zelphirkaltstahl@posteo.de> wrote: >=20 > > "This is where the eqv? predicate comes into picture. The eqv? is ex= actly > > the same as the eq? predicate, except that it will always return #t = for > > same primitive values." > > > > Of course SO is not a standard. Either it is simply wrong, or I > > misunderstood "primitive values" in that phrase. I thought: "Ah stri= ngs are > > a primitive value, so eqv? should work in all cases when comparing > > strings." However, this has been debunked. > > > Strings tend to be treated as primitive values, but technically they a= re > compound values, just as much as vectors are. And like vectors, you c= an > change the characters of a string without changing its identity. >=20 > > The only thing I do not quite understand yet is: What is the differe= nce > > between (eqv? ...) and (eq? ...) then? > > > Efficiency only. >=20 > > If (eqv? ...) is only #t if things get consolidated in the same stor= e > > place, would that not be the same as pointer equivalence? > > > Eq? is allowed to return #f on identical-looking characters and number= s > because they may or may not involve allocation. Characters and fixnum= s > (integers up to about 2^60) are generally not allocated and eq? will r= eturn > #t on them, but larger integers and other types almost certainly will = not: >=20 > (let ((i (* 48923498234892340 78902372789023)) (j (* 48923498234892340= > 78902372789023))) (eq? i j)) =3D> #f >=20 > That's because the values of both i and j have to be allocated, and > therefore aren't represented by the same pointers. But unlike strings= , you > can't mutate the digits of an integer, so providing eqv? gives us an > abstract notion of identity. The Scheme standards simplify the situat= ion > by saying that eq? may return #f even when eqv? returns #t in the case= s of > numbers and characters. >=20 > Because of these strange effects, I recommend (and this is just me) no= t > using eq? unless you can prove that you need the additional effi. >=20 > Note that (eq? 5 5.0) and (eqv? 5 5.0) are both #f, so if you want to > compare for numeric equality you should use (=3D 5 5.0) =3D> #t. The = reason > they are not identical is that they behave differently: (/ 5.0 2) =3D= > 2.5, > whereas (/ 5 2) =3D> 5/2. >=20 > Here's an example that shows us that Guile does not consolidate number= > literals, although it could: >=20 > (eqv? 3860180095872584138419938783820 3860180095872584138419938783820)= =3D>#f >=20 > (In R7RS, procedures that are eqv? aren't necessarily eq? either, and = in > R6RS even procedures that seem totally identical may be neither eq? no= r > eqv?. That's another story.) >