[M3devel] REFANY-keyed tables?

[JC Chu]

> ... The above technique works if you really want to simulate keying on the address (as it would be in a no-move GC environment.), which I suppose is what you wanted.

Yes, I was indeed in need of an immutable version of REFANY.

— JC Chu

-----Original Message-----
From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] 
Sent: Friday, February 28, 2014 23:16
To: m3devel at elegosoft.com
Subject: Re: [M3devel] REFANY-keyed tables?



On 02/26/2014 09:28 PM, Rodney M. Bates wrote:
>
>
> On 02/26/2014 11:08 AM, JC Chu wrote:
>> Hi,
>>
>> I need a REFANY-to-INTEGER table in my program but RefIntTbl.Default is giving me runtime errors.  Apparently Table(Key, Value) uses Key.Equal() and Key.Hash(), but those procedures in Refany, which is use to instantiate RefIntTbl, both raise a fatal exception.
>>
>
> The garbage collector is a (partially) compacting collector, which 
> means it can move a heap object and adjust all the pointers to it, if 
> it knows where they all are, which holds for some objects.  So the bit 
> contents of a REFANY can change. This means it is not possible to have a consistent Hash on the pointer value alone.
>
> So Refany.Hash is deliberately coded to raise this exception, to 
> prevent a far more insidious bug.
>
>> I’m a bit confused since a number of REFANY-keyed tables are shipped with CM3.  Is this actually the expected behavior or am I doing anything wrong?
>>
>
> Hmm, can you point out where these are?
>
> I have some pointer-keyed tables, but they use techniques like giving 
> every object an object sequence number field, explicitly initialized 
> when an object is allocated, and using that for the Hash function.  
> But this won't work for REFANY, because it can have no fields.
>

There is more to this.  The above technique works if you really want to simulate keying on the address (as it would be in a no-move GC environment.), which I suppose is what you wanted.

But in many cases, you might want to hash on the contents, not the address of the object, in which case, the technique used in juno-2, using actual data fields instead of an object sequence number is the right way.  For example, to turn the objects into atoms.

> So the table can only work on a narrower set of allocated object types than REFANY.
> If you need the table to hold addresses of a mixture of different 
> types, you can still do that with a hierarchy of OBJECT types, but 
> they will have to have a common supertype that contains whatever fields the Hash function needs for consistency.
>
> It would be possible that pointers get passed around in REFANY-typed 
> (statically) variables, but it is carefully arranged that they all 
> have an allocated type that has fields a Hash function can work on.  
> Hash would then have to do a NARROW or TYPECASE to the type it expected.
>
> Rodney Bates
>
>> Thanks.
>>
>> — JC Chu
>>
>
>