bug-guile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ludovic Courtès
Subject: bug#14792: Error in manual "(guile-2) Object Properties"
Date: Tue, 16 Jul 2013 20:53:03 +0200
User-agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux)

Mark H Weaver <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:
>
>> Mark H Weaver <address@hidden> skribis:
>>
>>> David Kastrup <address@hidden> 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’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]