[M3devel] small objects

[Rodney M. Bates]

Mika Nystrom wrote:
> 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.  

This is only true of _unrevealed  opaque subtypes_ of REFANY,
not of REFANY itself.   There is lots of existing code that uses REFANY,
and there, ISTYPE, NARROW, TYPECASE, and assigment can be and
regularly are used on it.   It is essential not to alter the semantics 
there.

Aside from actual semantic changes, I agree with Tony that we should
not burden any existing type with additional runtime work.  Even though
I expect small objects to support big performance gains in certain
important cases, non-tagged references will still greatly predominate
in most code.   Create new type(s) for tagged references.

> There are also good reasons for
> permitting this oddness (vide Smalltalk and Scheme small integers).
>