Parrot's got two main variable 'types'--value and reference.
Value types are types that are directly referenced--types whose PMCs actually represent themselves. When you get a PMC out of the symbol table or a lexical pad you get the value itself. Everything we have now is a value type. Traditional perl data types (and data types in most other *non* object oriented languages are like this)
Reference types are types that are indirectly referenced--you never get the PMC for the value itself, instead you get a PMC that points to the PMC with the value. This is the way objects are handled in most OO languages that I know about.
In either case, the PMC being assigned to *always* mediates in the assignment--that is, doing something like:
foo = bar;
gets foo involved. The assignment is *not* blind. The PMC being assigned to is responsible for managing the type checking and its own type coercion. If that above assignment should throw a type error, well... it does, and that's fine.
Note here that once a name slot gets a PMC in it, that PMC *stays* there for the lifetime of the slot, unless it's rebound. (And yes, this means store_global will be relatively little-used)
The issue we're facing isn't one of *assignment*--it's one of *rebinding*, where we do actually change which PMC is bound to a name slot. In this case there is no mediating PMC to decide whether the assignment is OK or how the assignment is handled. (In the case of containers with tie-like assignment overloading)
Traditionally this just *isn't* a problem--either the destination container always mediates the assignment (for OO languages, where you're slinging object references around and can see if the reference is what you want) or you're always coercing to a known type (like in C, with assignments to the base value types). There's also that third "go for it, good luck" category, where you're lying to the system about what pointers point to, but that's just C for you.
There's also a secondary issue of PMCs which change type, which can be an issue if we *do* have typed slot names--if the type is only checked on assignment you can have a variable change its type at runtime and violate the constraints placed on the slot. This is an interesting thing to deal with, and relatively little-dealt-with. (Most systems don't allow type changes without assignment, so it just doesn't happen)
So, generally, the problem isn't one, unless we do have typed names, in which casea we have a potentially significant problem and I'd better get on with the notification system quick.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
