GNU bug report logs - #14792
Error in manual "(guile-2) Object Properties"

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14792 in the body.
You can then email your comments to 14792 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: David Kastrup <dak <at> gnu.org>
To: bug-guile <at> gnu.org
Subject: Error in manual "(guile-2) Object Properties"
Date: Thu, 04 Jul 2013 20:03:42 +0200

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).  So something seems wrong in
that description.  Either integer values can _not_ be given properties
reliably, or the above needs to specify "distinguishable by `eqv?'" or
whatever else may be the underlying reality.

-- 
David Kastrup

Message #8 received at 14792 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: David Kastrup <dak <at> gnu.org>
Cc: 14792 <at> debbugs.gnu.org
Subject: Re: bug#14792: Error in manual "(guile-2) Object Properties"
Date: Fri, 05 Jul 2013 12:37:47 -0400

Hi David,

David Kastrup <dak <at> gnu.org> 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?

      Mark

Message #11 received at 14792 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Mark H Weaver <mhw <at> netris.org>
Cc: 14792 <at> debbugs.gnu.org, David Kastrup <dak <at> gnu.org>
Subject: Re: bug#14792: Error in manual "(guile-2) Object Properties"
Date: Sat, 06 Jul 2013 23:21:19 +0200

Mark H Weaver <mhw <at> netris.org> skribis:

> David Kastrup <dak <at> gnu.org> 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’t seem useful to me, so
my inclination would be to fix the manual, FWIW.

Ludo’.

Message #14 received at 14792 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 14792 <at> debbugs.gnu.org, David Kastrup <dak <at> gnu.org>
Subject: Re: bug#14792: Error in manual "(guile-2) Object Properties"
Date: Tue, 16 Jul 2013 11:59:01 -0400

Hi Ludovic,

ludo <at> gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw <at> netris.org> skribis:
>
>> David Kastrup <dak <at> gnu.org> 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’t 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

Message #17 received at 14792 <at> debbugs.gnu.org (full text, mbox):

From: David Kastrup <dak <at> gnu.org>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 14792 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: bug#14792: Error in manual "(guile-2) Object Properties"
Date: Tue, 16 Jul 2013 20:46:29 +0200

Mark H Weaver <mhw <at> netris.org> writes:

> 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.

Fixing the documentation will not change the behavior.  So they are not
worse off than before.

> '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?

object identity is checked by eq? and is conceptually different from
value equality.

When calling a thing an "object property", it is not helpful when it
does not behave like one.

-- 
David Kastrup

Message #20 received at 14792 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Mark H Weaver <mhw <at> netris.org>
Cc: 14792 <at> debbugs.gnu.org, David Kastrup <dak <at> gnu.org>
Subject: Re: bug#14792: Error in manual "(guile-2) Object Properties"
Date: Tue, 16 Jul 2013 20:53:03 +0200

Mark H Weaver <mhw <at> netris.org> skribis:

> ludo <at> gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw <at> netris.org> skribis:
>>
>>> David Kastrup <dak <at> gnu.org> 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’t 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.

[...]

> What's the argument on the other side?  Is there a compelling reason to
> use 'eq?' instead of 'eqv?' for object properties?

The argument would be the “ugly efficiency hack”.

But I hear your argument, and I’m fine with changing this accordingly.

Thanks,
Ludo’.

Message #23 received at 14792 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: David Kastrup <dak <at> gnu.org>
Cc: 14792 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: bug#14792: Error in manual "(guile-2) Object Properties"
Date: Tue, 16 Jul 2013 14:59:28 -0400

Hi David,

David Kastrup <dak <at> gnu.org> writes:

> Mark H Weaver <mhw <at> netris.org> writes:
>
>> '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?
>
> object identity is checked by eq? and is conceptually different from
> value equality.

The Scheme standards don't support your view.  The _only_ difference
between 'eq?' and 'eqv?' is that 'eqv?' is well-defined on numbers and
characters, whereas 'eq?' is unspecified for those types.

Numbers and characters do not have any notion of "object identity",
apart from operational equivalence.  For all values where "object
identity" makes any sense at all, 'eqv?' does what you want.

     Regards,
       Mark

Message #26 received at 14792 <at> debbugs.gnu.org (full text, mbox):

From: David Kastrup <dak <at> gnu.org>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 14792 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: bug#14792: Error in manual "(guile-2) Object Properties"
Date: Tue, 16 Jul 2013 21:30:50 +0200

Mark H Weaver <mhw <at> netris.org> writes:

> Hi David,
>
> David Kastrup <dak <at> gnu.org> writes:
>
>> Mark H Weaver <mhw <at> netris.org> writes:
>>
>>> '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?
>>
>> object identity is checked by eq? and is conceptually different from
>> value equality.
>
> The Scheme standards don't support your view.  The _only_ difference
> between 'eq?' and 'eqv?' is that 'eqv?' is well-defined on numbers and
> characters, whereas 'eq?' is unspecified for those types.

And why would that be if numbers were proper objects?  The difference is
_exactly_ there because they aren't.

> Numbers and characters do not have any notion of "object identity",
> apart from operational equivalence.

Which is why it does not make a lot of sense to assign "object
properties" to them.

-- 
David Kastrup

Message #29 received at 14792 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: David Kastrup <dak <at> gnu.org>
Cc: 14792 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: bug#14792: Error in manual "(guile-2) Object Properties"
Date: Tue, 16 Jul 2013 15:52:23 -0400

David Kastrup <dak <at> gnu.org> writes:

> Mark H Weaver <mhw <at> netris.org> writes:
>
>> David Kastrup <dak <at> gnu.org> writes:
>>
>>> Mark H Weaver <mhw <at> netris.org> writes:
>>>
>>> object identity is checked by eq? and is conceptually different from
>>> value equality.
>>
>> The Scheme standards don't support your view.  The _only_ difference
>> between 'eq?' and 'eqv?' is that 'eqv?' is well-defined on numbers and
>> characters, whereas 'eq?' is unspecified for those types.
>
> And why would that be if numbers were proper objects?  The difference is
> _exactly_ there because they aren't.

I don't know what you mean by "proper objects".  I guess maybe you mean
"objects with identity".

>> Numbers and characters do not have any notion of "object identity",
>> apart from operational equivalence.
>
> Which is why it does not make a lot of sense to assign "object
> properties" to them.

I understand that in the dominant "object oriented" programming
communities of today, the word "object" usually implies mutability and
identity, but the Scheme standards use the term differently.

In the Scheme standards, the word "object" is synonymous with "value".
R5RS section 1.1 states "Types are associated with values (also called
objects) rather than with variables."  Furthermore, R6RS consistently
calls numbers "objects", even though they lack "object identity" in the
sense that you mean.

     Mark

Message #32 received at 14792 <at> debbugs.gnu.org (full text, mbox):

From: David Kastrup <dak <at> gnu.org>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 14792 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: bug#14792: Error in manual "(guile-2) Object Properties"
Date: Tue, 16 Jul 2013 22:01:18 +0200

Mark H Weaver <mhw <at> netris.org> writes:

> David Kastrup <dak <at> gnu.org> writes:
>
>> Mark H Weaver <mhw <at> netris.org> writes:
>>
>>> David Kastrup <dak <at> gnu.org> writes:
>>>
>>>> Mark H Weaver <mhw <at> netris.org> writes:
>>>>
>>>> object identity is checked by eq? and is conceptually different from
>>>> value equality.
>>>
>>> The Scheme standards don't support your view.  The _only_ difference
>>> between 'eq?' and 'eqv?' is that 'eqv?' is well-defined on numbers and
>>> characters, whereas 'eq?' is unspecified for those types.
>>
>> And why would that be if numbers were proper objects?  The difference is
>> _exactly_ there because they aren't.
>
> I don't know what you mean by "proper objects".  I guess maybe you mean
> "objects with identity".
>
>>> Numbers and characters do not have any notion of "object identity",
>>> apart from operational equivalence.
>>
>> Which is why it does not make a lot of sense to assign "object
>> properties" to them.
>
> I understand that in the dominant "object oriented" programming
> communities of today, the word "object" usually implies mutability and
> identity, but the Scheme standards use the term differently.
>
> In the Scheme standards, the word "object" is synonymous with "value".
> R5RS section 1.1 states "Types are associated with values (also called
> objects) rather than with variables."  Furthermore, R6RS consistently
> calls numbers "objects", even though they lack "object identity" in the
> sense that you mean.

Well, eq?/eqv? are an inheritance from Lisp's eq/eql.  If there is no
clear conceptual difference any more, it would seem like a mistake to
keep two different operators around.

-- 
David Kastrup

Message #35 received at 14792 <at> debbugs.gnu.org (full text, mbox):

From: David Kastrup <dak <at> gnu.org>
To: 14792 <at> debbugs.gnu.org
Subject: Actually, this discussion is moot
Date: Sat, 27 Jul 2013 23:19:53 +0200

Object properties are implemented via key-weak hash tables and those
only support eq? as hash equality in a reliable way.

I actually can't determine how key-weak hash tables would deal with
immediate Scheme values: will they never get released, or will they get
released immediately?

From reading the documentation, I'd lean towards guessing the latter (as
for immediate Scheme values, there _never_ is a remaining reference).
That would likely make for some surprises to people, while the other
option would be good for memory leaks.

Either way, numbers seem like a bad idea for use in key-weak hash
tables.

-- 
David Kastrup

Message #40 received at 14792 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: David Kastrup <dak <at> gnu.org>
Cc: 14792 <at> debbugs.gnu.org, 18223 <at> debbugs.gnu.org, request <at> debbugs.gnu.org
Subject: Re: bug#18223: Duplicate of issue 14792
Date: Sun, 10 Aug 2014 23:00:37 -0400

merge 18223 14792
close 18223
close 14792
thanks

David Kastrup <dak <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.