On 11/13/2010 06:09 PM, Jonathan Worthington wrote: > With packed arrays, however, I'm less clear what they mean. Since the > point of a packed array is compact storage, there's no chance to > actually have containers. Thus does assignment to a slot in a compact > array ever make sense? There's not a container to look up and store > things in. > > While I can happily convince myself that: > > @x := 1; # works, just sticks 1 into the appropriate location > @x = 1; # dies, can't assign when there's no container > > Actually makes sense, I can also somewhat see users not liking it.
Indeed. As a user I think of the = operator as "put the thing on the RHS into the var (or array slot) on the LHS". I don't care about the underlying container model. I just care that 1) the RHS now contains a 1 2) I don't get any spooky action at a distance. I'd like those two points to remain the same for packed arrays. > So my questions are: > > 1) What semantics would users expect? Is it OK to say "no, you can't > assign" in this case? see above > 2) If proposing that both should work, what, roughly, would that look > like at an implementation level? > > When answering (2), consider that: > > @x = 42; > > Currently really means: > > &infix:<=>(@x, 42); > > That is, we really do look up the container and then perform an > operation in it. So if you de-sugar it all, it's kinda like: > > VAR(@x).STORE(42) > > So just saying "oh, just given assignment semantics like binding ones" > is not so simple, since it'd seem that we do not get anything we could > call .STORE on back from @x from a natively typed array. > > Any thoughts? (Same questions/answers apply for natively typed > attributes in objects, or at least I'd be very surprised if they are > different.) I don't have a good idea right now; just consider that whatever ends up storing a 1 into the array also might need to do a coercion; after all an Int is not an int. Maybe the two things (handling of assignment and coercion) are somehow related? Do we always know at compile time that a certain container is natively typed? if yes, maybe we can automagically rewrite assignment to binding at compile time... If nobody comes up with a practical idea on how to solve it, I'd grumpily accept only binding for storing things in a natively typed container. We'd need a *VERY* good error message in that case. Cheers, Moritz