Just so everyone doesn't have to go digging through the archives... Here are links to the postings, and some extracts which seemed to provide context for the current thread.
http://nntp.x.perl.org/group/perl.perl6.internals/12804 http://nntp.x.perl.org/group/perl.perl6.internals/12809 http://nntp.x.perl.org/group/perl.perl6.internals/13007 We've been kind of sloppy with variables and values so far--not too surprising as perl 5 was, and many languages (like C) don't make much of a distinction, and the distinction doesn't much matter even where it does exist. We can't do that any more, unfortunately. That's something of a pity, as it makes things easier, which should've been a clue that we don't get to do it that way. :) A "thing" has three parts, a name (which is optional), a container, and the contents of the container. The name lives in a symbol table or scratchpad somewhere, and has a pointer to the container. That's *all* it has, and is otherwise of no particular use. The container part is the variable. It holds the value, and is what mediates assignment. You must go through the variable when storing the value, and you must go through the variable when fetching the value. Unfortunately this also means, in the general case, when doing any access at all of the value in the variable. Luckily in the normal case we can skip this indirection. Variables also have properties. The thing in the container is the value. It also has a type, a vtable that mediates activities involving the value, and properties. Which are separate from the variable properties. (Which, again, are separate from attributes) What does this mean for us? Well, first it means we need to conceptually split "variables" into three parts, rather than two as we have been. It also means that we need to (or at least really should) split vtables up into parts, so we can pull them upwards as appropriate. That way we can promote vtable pieces where appropriate, when the value and variable are of the same type, to cut out dispatch overhead. And in those cases where we can't do that, we can do the normal two-level access. (Though hopefully we can avoid it for most anything besides objects and aggregates) http://nntp.x.perl.org/group/perl.perl6.internals/13196 http://nntp.x.perl.org/group/perl.perl6.internals/13207 >Do you have a more verbose description of variable/value separation? Sure. Aggregates are a good one. For example, let's assume you have an array that can only hold real objects. The objects are the values, while the array itself is the variable. You *must* go through the variable's vtable to find a value, while when you manipulate the data you need to use the vtable in the value. Tied data's another one. If you tie a scalar, the variable is tied not the value in the variable. But whenever you access the data in the variable the variable needs to be involved in the fetch or store, while the value is what's involved with any actual manipulation. [...] Well, with the design as it is, we theoretically need to go through the variable's vtable every time we need to act on the value in the variable--we have to do a fetch then dispatch through the fetched value's vtable to act on it. What I'd like to be able to do is, for variables that are effectively passive and don't actually have to get involved, to skip that extra level of indirection and promote the value's vtable functions into the variable's vtable. http://nntp.x.perl.org/group/perl.perl6.internals/13219 So we would have e.g.: - Plain scalar: vtable->var.get_integer => return cache.int_val ->val.get_integer => return cache.int_val - Tied scalar: vtable->var.get_integer => call tie magic (updating the value) => ->val.get_integer => return cache.int_val http://nntp.x.perl.org/group/perl.perl6.internals/13306 Close. (Or the same if I'm misreading) Like: -tied vtable->var.get_integer => call tie magic to get value PMC ->tie_magic_returned_pmc.get_integer => reurn cache.int_val http://nntp.x.perl.org/group/perl.perl6.internals/13314 Your descriptions seems to include another PMC in tie_magic, while mine just passes the value PMC to tie_magic. tie_magic updates the value, then the normal scalar behaviour jumps in. This question does not seem to be resolved in the archive. http://nntp.x.perl.org/group/perl.perl6.internals/13337 This posting describes a test program attachment, which unfortunately didn't make it into either archive. There was a then a two month hiatus, broken by the current thread. Archivally, Mitchell
