[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Shorthand for appending to a table (was Re: 5.2 feature list?)
- From: David Olofson <david@...>
- Date: Tue, 12 Sep 2006 22:42:45 +0200
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
EEL supports both explicitly;
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)".)
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
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
* 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
* 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 --'