Ivan Shmakov scripsit:
> Given that the basic idea of hashing is to produce a key out of
> the object’s /value/, the change of the value – and mutation
> does just that – changes the hash.
Well, yes and no. SRFI 69 and other Scheme hash table frameworks
support at least two
Am 18.12.2015 um 18:35 schrieb John Cowan:
> Ivan Shmakov scripsit:
>
>> Given that the basic idea of hashing is to produce a key out of
>> the object’s /value/, the change of the value – and mutation
>> does just that – changes the hash.
>
> Well, yes and no. SRFI 69 and other
I may be completely misunderstanding something here, but don't you have to
use equal? and not eq? for record structures?
K.
On Wed, Dec 16, 2015 at 10:09 PM, Jörg F. Wittenberger <
joerg.wittenber...@softeyes.net> wrote:
> Ah, great to learn.
>
> a) You are right: Per SRFI-69 it is actually
Am 17.12.2015 um 11:08 schrieb Kristian Lein-Mathisen:
> I may be completely misunderstanding something here, but don't you have to
> use equal? and not eq? for record structures?
AFAIK eq? should hold true when the two objects are the same. Equal?
will compare all the slots. (The latter is not
On Wed, Dec 16, 2015 at 09:47:31PM +0100, Jörg F. Wittenberger wrote:
> Hi,
>
> I always assumed that (make-hash-table eq?) would create a hash table
> usable with arbitrary chicken objects as keys.
>
> That is especially structures like objects created via define-record
> should be valid as
Hi,
I always assumed that (make-hash-table eq?) would create a hash table
usable with arbitrary chicken objects as keys.
That is especially structures like objects created via define-record
should be valid as keys. That is: referencing the table using the very
same object (comparing eq? to the
Ah, great to learn.
a) You are right: Per SRFI-69 it is actually undefined. Per chicken
manual it returns the new value associated with key.
As I've seen the latter (e.g. in the iup egg) actually being used, we
might at least want to keep the behavior in chicken.
b) But does not matter much.
