Re: Shorthand for appending to a table (was Re: 5.2 feature list?)

[David Olofson <david@...>]

On Tuesday 12 September 2006 17:14, Philippe Lhoste wrote:
[...]
> Frankly, sometime I really wish to have this += (-=) notation, even 
> though I am not fan to make Lua look like C, unlike many users...
> But I guess it has unwanted side-effects or problems.

Can't tell if there would be any serious side effects if this was 
applied to Lua, but it seems to work for EEL, which is similar in 
many ways, but has a more C-like syntax.

However, there is one thing to keep in mind here: There is a 
difference between inplace operations (modifying the object) and 
"functional style" (creating new instances.)

At lesat to me, the += style syntax suggests functional style, whereas 
something like x:append(y) suggests that the actual instance of x is 
being modified.

EEL supports both explicitly;

	Inplace/destructive:
		a.+ "another element";

		(The string is appended to the array referred
		to by 'a'. You can think of "x.+ y" as
		syntactical sugar for "x.plus(y)".)

	Functional/non destructive:
		a += "another element";

		(A new array with "another element" appended
		to it is created and then assigned to 'a',
		*exactly* as if you would have written
		a = a + "another element".)

At first, this may not seem to make much of a difference - but there 
is a huge difference if there are other references to the object 
being operated on or "with". The former modifies the original object, 
whereas the latter creates a new one, leaving the original instance 
alone.

I find the distinction useful, and I prefer this kind of things 
explicit, but then again, I've probably spent way too much time 
coding in asm and C. ;-)

Frankly though, there is no way to completely avoid the distinction, 
so why try ignoring it? Even if the language tries to support only 
one way of doing it, there are still situations where the programmer 
will have to understand what's really going on.


> Should we accept x, y += 1?
> a, b += x, y?

As in, the former means "add 1 to both x and y" and the latter is 
equivalent to "a += x; b += y;" ?

I do both in EEL, though it's just one of those highly experimental 
things I threw in without really knowing how it would turn out. 
(Comes pretty much free as a side effect of the way the compiler is 
designed, so I figured I'd try it.) I've written tens of tousands of 
lines of EEL code, using this feature quite a bit, and it hasn't 
bitten back so far, so I'd say the idea does indeed work, at least...

That said, I don't think this feature is of all that much use in 
itself. All it really can do on it's own is allow you to write more 
cryptic looking code, if you're into that. ;-)

Where I actually use it in EEL, is to save typing and avoid 
intermediate "dummy" variables;
	deep.down.somewhere.point = table [.a 0, .b 0];
	deep.down.somewhere.point.(a, b) += 10;
	deep.down.somewhere.point.(a, b) *= 2;
	deep.down.somewhere.point.(a, b) += 2, 4;

I'm thinking it should be trivial, and even more useful, to make this 
work as well:
 	r = deep.down.somewhere.point.(a ** 2 + b ** 2);

As of now, the whole "x.(a, b, c, ...)" construct is handled as a 
simple special case of the . indexing operator, basically just 
unrolling it to "x.a, x.b, x.c, ...", rather than treating what's 
inside the parentheses as any expression. (What was I thinking...?)


> Perhaps more trouble than it is worth.

The implementation part depends on the compiler. In the case of EEL, 
it was pretty easy to implement. Might be harder or simpler with Lua.

Either way, I think the effects on the language is the more 
problematic part.
	* Can you just add this behavior to the "coma
	  separate list of things" parser rule(s) without
	  nasty side effects?

	* Can you do it without increasing the risk of
	  typos compiling into code that doesn't do what
	  you intend?

	* Can you do it in a way that it is obvious what
	  the code does, even to readers who are not
	  very familiar with the new feature?

	* Can you add the feature in a non-intrusive way,
	  and still have a syntax that doesn't make it
	  overly cumbersome to access?


In the case of EEL, it's just me and about one more guy who gets to 
modify code to deal with any "brilliant" changes I make to the 
language. (So far, my changes have improved things enough that that 
other guy hasn't been complaining about them breaking old code. ;-) 
My philosophy here is "rather break some code now, than curse over a 
broken language forever."


//David Olofson - Programmer, Composer, Open Source Advocate

.-------  http://olofson.net - Games, SDL examples  -------.
|        http://zeespace.net - 2.5D rendering engine       |
|       http://audiality.org - Music/audio engine          |
|     http://eel.olofson.net - Real time scripting         |
'--  http://www.reologica.se - Rheology instrumentation  --'