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[0] := 1; # works, just sticks 1 into the appropriate location
> @x[0] = 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[0] = 42;
> 
> Currently really means:
> 
> &infix:<=>(@x[0], 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[0]).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[0] 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

Reply via email to