bug#14792: Error in manual "(guile-2) Object Properties"

bug#14792: Error in manual "(guile-2) Object Properties"

[David Kastrup]

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

bug#14792: Error in manual "(guile-2) Object Properties"

[Mark H Weaver]

Hi David,

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

bug#14792: Error in manual "(guile-2) Object Properties"

[Ludovic Courtès]

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

> David Kastrup <dak@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’.

bug#14792: Error in manual "(guile-2) Object Properties"

[Mark H Weaver]

Hi Ludovic,

ludo@gnu.org (Ludovic Courtès) writes:

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

bug#14792: Error in manual "(guile-2) Object Properties"

[David Kastrup]

Mark H Weaver <mhw@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

bug#14792: Error in manual "(guile-2) Object Properties"

[Ludovic Courtès]

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

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

bug#14792: Error in manual "(guile-2) Object Properties"

[Mark H Weaver]

Hi David,

David Kastrup <dak@gnu.org> writes:

> Mark H Weaver <mhw@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

bug#14792: Error in manual "(guile-2) Object Properties"

[David Kastrup]

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

> Hi David,
>
> David Kastrup <dak@gnu.org> writes:
>
>> Mark H Weaver <mhw@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

bug#14792: Error in manual "(guile-2) Object Properties"

[Mark H Weaver]

David Kastrup <dak@gnu.org> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> Mark H Weaver <mhw@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

bug#14792: Error in manual "(guile-2) Object Properties"

[David Kastrup]

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

> David Kastrup <dak@gnu.org> writes:
>
>> Mark H Weaver <mhw@netris.org> writes:
>>
>>> David Kastrup <dak@gnu.org> writes:
>>>
>>>> Mark H Weaver <mhw@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

bug#14792: Actually, this discussion is moot

[David Kastrup]

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