[M3devel] small objects

[Mika Nystrom]

Tony Hosking writes:
...
>
>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.
...

But it's correct, isn't it, that you get an extra one-bit check for
ISTYPE, TYPECASE, TYPECODE, and NARROW?  There's no problem with
dereferencing, nor is there a problem with assignment.  No need to
introduce overhead for either of those, since dereferencing can't
happen and assignment is transparent (or an implicit NARROW).

I was going to say to Rodney that I think that Modula-3 programmers
know that using REFANY does cause some overhead (it must), and in
any case the normal ISTYPE code is going to be hundreds of times
slower than the single-bit check, and no one (except me) seems to
have had any problem with this so far.

So yes, the change does affect existing code, but only code that's
already using REFANY, ISTYPE, TYPECASE, and the extra overhead is
very minor compared to the work ISTYPE and TYPECASE are already
doing.

I think I really like the idea of boxing it in this other opaque
type if that doesn't cause any problems, specifically because it
doesn't make any semantic change to the language at all.

Actually, it is important for the application of embedded interpreters
that these tagged types be compatible with a standard REFANY.  The
whole point is to be able to write a fast interpreter that deals
in normal Modula-3 types and not in a special parallel hierarchy...
Look at how the various languages embedded in Java (JScheme, Groovy,
Jython(?)) do these things: it's really pretty nifty.  But *they*
can't do efficient small integers!

     Mika