bug#18223: [PATCH] Fix thinko concerning object property docs

bug#18223: [PATCH] Fix thinko concerning object property docs

[David Kastrup]

Numeric values cannot reliably be distinguished using eq? and have no
guaranteed object identity.

Signed-off-by: David Kastrup <dak@gnu.org>
---
 doc/ref/api-utility.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/ref/api-utility.texi b/doc/ref/api-utility.texi
index ffdf276..e2b60e2 100644
--- a/doc/ref/api-utility.texi
+++ b/doc/ref/api-utility.texi
@@ -222,7 +222,7 @@ setting of @var{obj}'s @var{property}.
 
 A single object property created by @code{make-object-property} can
 associate distinct property values with all Scheme values that are
-distinguishable by @code{eq?} (including, for example, integers).
+distinguishable by @code{eq?} (ruling out numeric values).
 
 Internally, object properties are implemented using a weak key hash
 table.  This means that, as long as a Scheme value with property values
-- 
1.9.1

bug#18223: Duplicate of issue 14792

[David Kastrup]

This is actually a duplicate of issue 14792 which has been ignored for
over a year by now.

Please see <URL:http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14792#35>
for the reason the provided patch (namely discouraging the use of
numbers for object properties) is the only one making sense.

Here is the rationale in code: object properties are implemented via
key-weak hash tables, and weak hash tables will not work with eqv? as
equivalence since key-weakness is related to garbage collection which
cannot consider anything but eq?-equivalence.

scheme@(guile-user)> (define x (make-weak-key-hash-table))
scheme@(guile-user)> (hashv-set! x 100000000000000000000 #t)
$6 = #t
scheme@(guile-user)> (gc)
scheme@(guile-user)> (hashv-ref x 100000000000000000000)
$7 = #f

Guile and/or Scheme do not store the equivalence relation in the
hashtable itself, and user-definable hash functions may establish
arbitrary relations regarding key uniqueness that have no clear relation
to the object identity used by garbage collection.

-- 
David Kastrup

bug#18223: Duplicate of issue 14792

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

I can't reproduce it, but I'm using the latest mater. Could you provide
your version?
 2014年8月9日 下午5:47于 "David Kastrup" <dak@gnu.org>写道：

>
> This is actually a duplicate of issue 14792 which has been ignored for
> over a year by now.
>
> Please see <URL:http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14792#35>
> for the reason the provided patch (namely discouraging the use of
> numbers for object properties) is the only one making sense.
>
> Here is the rationale in code: object properties are implemented via
> key-weak hash tables, and weak hash tables will not work with eqv? as
> equivalence since key-weakness is related to garbage collection which
> cannot consider anything but eq?-equivalence.
>
> scheme@(guile-user)> (define x (make-weak-key-hash-table))
> scheme@(guile-user)> (hashv-set! x 100000000000000000000 #t)
> $6 = #t
> scheme@(guile-user)> (gc)
> scheme@(guile-user)> (hashv-ref x 100000000000000000000)
> $7 = #f
>
> Guile and/or Scheme do not store the equivalence relation in the
> hashtable itself, and user-definable hash functions may establish
> arbitrary relations regarding key uniqueness that have no clear relation
> to the object identity used by garbage collection.
>
> --
> David Kastrup
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1704 bytes --]

bug#18223: Duplicate of issue 14792

[David Kastrup]

Nala Ginrut <nalaginrut@gmail.com> writes:

> I can't reproduce it, but I'm using the latest mater. Could you provide
> your version?

My version is 2.0.9, but more importantly my architecture is 32bit.
Just add enough zeros to move beyond the largest immediate integer, and
you'll likely see the same effect.

-- 
David Kastrup

bug#14792: bug#18223: Duplicate of issue 14792

[Mark H Weaver]

merge 18223 14792
close 18223
close 14792
thanks

David Kastrup <dak@gnu.org> writes:

> Here is the rationale in code: object properties are implemented via
> key-weak hash tables, and weak hash tables will not work with eqv? as
> equivalence since key-weakness is related to garbage collection which
> cannot consider anything but eq?-equivalence.
>
> scheme@(guile-user)> (define x (make-weak-key-hash-table))
> scheme@(guile-user)> (hashv-set! x 100000000000000000000 #t)
> $6 = #t
> scheme@(guile-user)> (gc)
> scheme@(guile-user)> (hashv-ref x 100000000000000000000)
> $7 = #f

Indeed, you are right.  I added a proper commit message to your patch,
and have applied it to the stable-2.0 branch.  I'm closing both bugs.

     Thanks!
       Mark

bug#18223: And here's direct proof that the doc is wrong:

[David Kastrup]

scheme@(guile-user)> (define wooziness (make-object-property))
scheme@(guile-user)> (set! (wooziness 5) #t)
$1 = #t
scheme@(guile-user)> (wooziness 5)
$2 = #t
scheme@(guile-user)> (set! (wooziness 1000000000000000000) #t)
$3 = #t
scheme@(guile-user)> (wooziness 1000000000000000000)
$4 = #f
scheme@(guile-user)> 

The property persists for 5 and evaporates for 1000000000000000000.
There is no reliable way to know whether it will persist for numbers.

And since Guile refuses to commit to guaranteeing (lambda (x) (eq? x x))
to return #t when x may be a number and since there is no guarantee just
which numbers may be represented by immediate values, there is no
context in which an object property on a number may safely be retrieved.

-- 
David Kastrup