[M3devel] small objects

[Rodney M. Bates]

Tony Hosking wrote:
> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote:
>
>> Mika Nystrom wrote:
>>>
>>> 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.
>
> Pre-existing code won't be able to do anything useful with tagged 
> REFANYs:
>
> Suppose we have
>
> VAR r: REFANY = SmallInteger.FromInt(0);
>
> then
>
> ISTYPE(r, REFANY) => TRUE
> ISTYPE(r, T) => FALSE for any T # REFANY
>
> Similarly, for TYPECASE, r will only trigger the REFANY branch.
>
> NARROW(r, REFANY) => r
> NARROW(r, T) => run-time error for any T #REFANY
>
> VAR x: REFANY  => assignment succeeds
> VAR x: T := r  => run-time error for any T # REFANY (because of 
> implicit NARROW)

I think I am getting a bit lost in all the proposals, variations, 
counterproposals, etc., but
from this argument I am inferring that your plan is that only variables 
declared REFANY
and not any proper subtype of REFANY can ever have a value with a tag 
bit set?   Then
the 4 narrowing operations, when and only when applied to an expression 
of static
type REFANY, would change to make a runtime check for a tag bit and fail 
if it's set?
It would take this to prevent a tagged value from getting into a 
variable declared a
proper subtype of REFANY, which can be dereferenced.

This would preclude making your abstract data type an opaque subtype of 
REFANY,
and would mean all supposedly unrelated ADT modules that used the tag 
technique
could be broken by client code that mixed up the REFANY values of one of 
them with
those of another.  I consider this a definite breach of Modula-3's 
otherwise bulletproof
type safety. 
>
> It is impossible to dereference an expression statically typed as 
> REFANY, so there is no need for a "tagged" check on dereference.
> Because a tagged REFANY cannot be assigned to anything other than 
> something typed REFANY, it can never propagate to a place where it can 
> be dereferenced.
>
>> 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.
>
> I'm not sure that we are seeing any semantic changes at all.  And with 
> Mika's definition of SmallInteger.T as a "boxed" INTEGER object 
> (actually it would be a subrange for values that fit into 
> BITSIZE(Word.T)-1 bits), it is essentially transparent.  It just 
> happens to be a run-time optimization that unboxes the INTEGER value.
>
>
> I think I can implement the compiler and run-time support for this 
> very quickly.
>
>