[M3devel] small objects

[Mika Nystrom]

Hmm, ok, there's one big difference between what you're saying and
what Tony and I have been talking about.  (I think your understanding
sounds pretty correct.)

You want to do objects other than small integers.  Like what?  And why?
I was thinking the trick would apply only to one specific type of integer.

Hmm, so your idea is to statically determine what type the references
can have if they are non-references.  So you are thinking to put various
kinds of subranges into the "TAGGED" types.  But you have to be able to
determine, statically, which subrange it is... am I understanding this
correctly?

    Mika

"Rodney M. Bates" writes:
>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.
>>
>>