MOO-cows Mailing List Archive


Re: ALPHA-TEST release of LambdaMOO version 1.8.0alpha6

Roger Crew writes:
> Is there a reason (i.e., aside from time pressures) 
> that you're not allowing
>      { TARGETS }
> to itself be a target?

I had originally expected to allow arbitrary assignables on the left-hand side,
so that you could do things like this:

	{x.prop, @z[i..j], y.prop[k]} = foo;

In this model of things, anything that was ever allowed on the left-hand side
of an assignment would also have been allowed as a target in a scattering
assignment.  As I worked out the implementation, though, it became clear that I
was heading into quite deep water, mostly concerning the order of evaluation of
the various bits and pieces.  I scaled back from that to the current spec
without ever considering your midway point.  If you take a look at the
implementation (in particular, at the structure of the new EOP_SCATTER opcode),
you'll see that it's not very close to handling what you described, though
maybe there's a way to overload parts of the operands to describe it.

It's a pretty minor point, though, since you can usually do the nesting in
successive assignments (assuming that your default-value expressions don't
depend on the variables assigned in those later assignments).

Maybe I should just go back to pleading time pressures... :-)



Home | Subject Index | Thread Index