[M3devel] small objects

[Mika Nystrom]

Tony, 

I think you have convinced me that what you say is workable.

However I share Hendrik's concern that using RT0.RefanyTypecode
might hurt some day in the future, even if I think you have shown
pretty convincingly that it doesn't hurt today.  How about my "second
proposal".  Do pretty much what you suggest but instead of returning
RT0.RefanyTypecode, return TYPECODE(TaggedInteger.T), where
TaggedInteger.T is an object type that is declared entirely privately
to the TaggedInteger unsafe module...  this also gives a completely
obvious implementation for pickling the tagged integers.  Simply
convert them to TaggedInteger.T and pickle that.  An implementation
that doesn't support tagged integers in pointers could also allocate
"real" TaggedInteger.Ts.... not sure that is useful though or if
it just confuses.  Actually I think it is useful, because it lets
you represent the values even if unpickling in a system that doesn't
support tagged integers in REFANYs.

I would go so far as saying this... I believe it is possible to
guarantee that any safe code outside of the TaggedInteger module
couldn't distinguish between a REFANY that holds a tagged integer
vs. one that holds a reference to a (heap-allocated) TaggedInteger.T.
How's that for not breaking the language definition?

Hendrik, I think Tony's and my arguments that you can't break any
existing code by allowing the squirreling away of integers into
REFANYs are pretty solid.  Pre-existing code simply can't do anything
useful with unrevealed REFANYs.  There are also good reasons for
permitting this oddness (vide Smalltalk and Scheme small integers).

     Mika

Tony Hosking writes:
>You can't do anything directly with a REFANY.  To use it you need to  
>narrow to a concrete type.  We would disallow that for tagged values  
>with a run-time check. Existing code needs to check (using ISTYPE or  
>TYPECASE), or know by design, what type is safe to narrow to, before  
>narrowing anyway. So I think all is ok.
>
>On 7 Apr 2009, at 22:12, hendrik at topoi.pooq.com wrote:
>
>> On Tue, Apr 07, 2009 at 04:55:12PM +1000, Tony Hosking wrote:
>>> After all of this -- I may simply be coming back around to your
>>> original proposal -- why not simply declare:
>>>
>>> TaggedInteger.T = REFANY;
>>
>> You'd be adding a range of integers to the set of things a REFANY  
>> could
>> hold.  Might that enable one to pass these integers as REFANYs to
>> existing code that isn't expecting it?  Might code that checks its  
>> input
>> for suitable preconditions then let this case slide?  Or would any  
>> test
>> that checks that a REFANY holds an appropriate reference or NIL
>> automatically manage to exclude tagged integers, just as it excludes
>> inappropriate references?
>>
>> I don't mind the proposed semantics for REFANY -- if it had been
>> there from the beginning.  But with a lot of existing code in existing
>> libraries, would it be safer to use a new type for this new meaning?
>>
>> You could, of course, stull have an unsafe module that defines
>>
>> TaggedInteger.T = NEWTYPEWITHNEWNAME;
>>
>> -- hendrik