Re: ALPHA-TEST release of LambdaMOO version 1.8.0alpha6

• Date: Tue, 16 Jan 1996 14:52:24 PST
• From:
  Pavel Curtis <pavel@parc.xerox.com>
• Cc: "MOO-Cows@parc.xerox.com" <MOO-Cows@parc.xerox.com>
• In-reply-to: Roger Crew's message of "Tue, 16 Jan 1996 13:12:19 PST" <c=US%a=_%p=msft%l=RED-77-MSG960116131220DZ008701@red-01-imc.itg.microsoft.com>

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... :-)

	Pavel

• RE: ALPHA-TEST release of LambdaMOO version 1.8.0alpha6
• From: Roger Crew <rfc@microsoft.com>

• Prev: RE: ALPHA-TEST release of LambdaMOO version 1.8.0alpha6
• Next: ALPHA-TEST release of LambdaMOO version 1.8.0alpha6
• Index: MOO-cows
• Thread: MOO-cows