From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.bugs Subject: bug#14792: Error in manual "(guile-2) Object Properties" Date: Tue, 16 Jul 2013 11:59:01 -0400 Message-ID: <87li563396.fsf@tines.lan> References: <87ehbedwxt.fsf@fencepost.gnu.org> <87siztarok.fsf@tines.lan> <87wqp3mlkg.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1373990421 24445 80.91.229.3 (16 Jul 2013 16:00:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 16 Jul 2013 16:00:21 +0000 (UTC) Cc: 14792@debbugs.gnu.org, David Kastrup To: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Tue Jul 16 18:00:21 2013 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Uz7fn-0007m3-FM for guile-bugs@m.gmane.org; Tue, 16 Jul 2013 18:00:19 +0200 Original-Received: from localhost ([::1]:46007 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uz7fn-0005An-4e for guile-bugs@m.gmane.org; Tue, 16 Jul 2013 12:00:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39666) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uz7fd-000511-AU for bug-guile@gnu.org; Tue, 16 Jul 2013 12:00:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uz7fa-00048Y-GT for bug-guile@gnu.org; Tue, 16 Jul 2013 12:00:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36118) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uz7fa-00048K-Dh for bug-guile@gnu.org; Tue, 16 Jul 2013 12:00:06 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Uz7fZ-0004ff-D4 for bug-guile@gnu.org; Tue, 16 Jul 2013 12:00:05 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mark H Weaver Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Tue, 16 Jul 2013 16:00:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14792 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 14792-submit@debbugs.gnu.org id=B14792.137399037017818 (code B ref 14792); Tue, 16 Jul 2013 16:00:04 +0000 Original-Received: (at 14792) by debbugs.gnu.org; 16 Jul 2013 15:59:30 +0000 Original-Received: from localhost ([127.0.0.1]:58667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Uz7ez-0004dJ-Td for submit@debbugs.gnu.org; Tue, 16 Jul 2013 11:59:30 -0400 Original-Received: from world.peace.net ([96.39.62.75]:53870 ident=hope0) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Uz7ex-0004cz-RV for 14792@debbugs.gnu.org; Tue, 16 Jul 2013 11:59:28 -0400 Original-Received: from 209-6-120-240.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com ([209.6.120.240] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Uz7eq-000289-2O; Tue, 16 Jul 2013 11:59:20 -0400 In-Reply-To: <87wqp3mlkg.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sat, 06 Jul 2013 23:21:19 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:7230 Archived-At: Hi Ludovic, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Mark H Weaver skribis: > >> David Kastrup writes: >> >>> The manual states in "Object Properties": >>> >>> A single object property created by `make-object-property' can >>> associate distinct property values with all Scheme values that are >>> distinguishable by `eq?' (including, for example, integers). >>> >>> Integers are not documented to be reliably distinguishable by eq? (which >>> means that equal integers might not be eq). >> >> Indeed, good point! >> >> I think we should change object-properties to use 'eqv?' hash operations >> instead of 'eq?'. The only advantage to 'eq?' is a marginal efficiency >> benefit, but that's no doubt lost in the noise, not only from the hash >> table operations but from the use of fat mutexes. >> >> The only functional difference between Guile's 'eq?' and 'eqv?' is that >> 'eq?' is not reliable on numbers. Our manual has been telling people >> for years that integers can be used as keys for object properties. >> Therefore, we should make it so. IMO, anyway. >> >> What do other people think? > > Associating object properties with numbers doesn=E2=80=99t seem useful to= me, so > my inclination would be to fix the manual, FWIW. I can easily think of many possible uses for this, e.g. for memoizing unary numeric functions, associating application-specific data structures with file descriptors or array indices, etc. Regardless, our manual has been telling people they could do this for a long time. To make matters worse, those who have tried using object-properties have likely observed that it works as advertised. They probably don't realize that it will silently fail for large integers. 'eqv?' is Scheme's fundamental "operational equivalence" predicate. 'eq?' is just an ugly efficiency hack, a poor cousin of 'eqv?' that fails in surprising ways. No _correct_ program is ever broken by making 'eq?' an alias to 'eqv?'. Many programs contain subtle bugs because of their inappropriate use of 'eq?'. What's the argument on the other side? Is there a compelling reason to use 'eq?' instead of 'eqv?' for object properties? Regards, Mark