# New operators?

66 messages
1234
Open this post in threaded view
|

## New operators?

 ```Hi I am carrying this in my mind for some time now and I guess, I am not alone: What about a few new operators? I think most people with a C/C++ background are missing the += *= etc operators - and in my opinion these are really useful. I have quite alot of vectoroperations in my luacode and it would be really great if I could write x,y,z += vx,vy,vz or x,y,z /= len,len,len instead of x,y,z = x + vx, y + vy, z + vz or x,y,z = x / len, y / len, z / len It can be easier read and understood and is less to write. Are there any reasons that speak against such operators (btw., the # operator is was a great addition to 5.1)? greetings Eike Decker ```
Open this post in threaded view
|

## Re: New operators?

 ```Eike Decker wrote: ``````Hi I am carrying this in my mind for some time now and I guess, I am not alone: What about a few new operators? I think most people with a C/C++ background are missing the += *= etc operators ```- and in my opinion these are really useful. ```I have quite alot of vectoroperations in my luacode and it would be really great if I could write x,y,z += vx,vy,vz or x,y,z /= len,len,len instead of x,y,z = x + vx, y + vy, z + vz or x,y,z = x / len, y / len, z / len ```It can be easier read and understood and is less to write. ```Are there any reasons that speak against such operators (btw., the # operator is was a great addition to 5.1)? greetings Eike Decker ``` ``` += operators aside, introducing a,b,c += d,e,f is just silly.. ```If you do lots of vector math in your app, you really should create some vector magic for it, such as this, http://giger.robot9.net/pub/vector.html It's reasonably fast, can be made faster, and allows you to do stuff like this: ``` local a = vector:new( 1, 2, 3 ) local b = vector:new( 4, 5, 6 ) local c = a + b; c = c + vector:new( 1,1,1 ); etc etc.. ```
Open this post in threaded view
|

## RE: New operators?

 In reply to this post by Eike Decker-2 ```Eike Decker wrote: > I am carrying this in my mind for some time now and I guess, I am not > alone: > > What about a few new operators? > I think most people with a C/C++ background are missing the += *= etc > operators - and in my opinion these are really useful. > > [...] > > Are there any reasons that speak against such operators (btw., the # > operator is was a great addition to 5.1)? Here are some very personnal reasons: 1) In Lua, contrary to C/C++, assignments are statements but not expressions. C++ syntax relies heavily on the fact that assignations are expressions. In Lua you have a single assignment operator, just one, which is not in the same category at all than binary operators (+ - * / % .. and or). So adding new assignments operators means: - having several assignment operators instead of just one (and going from 1 to 2+ is much more difficult than going from n to n+1) - introducing ambiguity between assignment and expressions (because += does both) - introducing += will encorage people to ask for ++, both prefixed and suffixed, and ++ will encourage people to ask for assignments to become expressions, which will completely change the syntax and semantics of Lua 2) It also makes it much easier to overide the semantics without thinking to all corner cases introduced (C++ const-ness and copy constructor mechanism are in part consequences of the ambiguity mentionned above). 3) The very fact that expressions and statements are distinct things in Lua makes the language much easier to teach to non-programmers, which constitute a non-marginal part of Lua users. I don't know which are the official reasons. The recurrence of that topic definitively means that we need some online list of frequently asked and rejected Lua heavy modifications. ```
Open this post in threaded view
|

## Re: New operators?

 ```An alternative to assignment operators (+=, etc) might be to have a shorthand for referring to the variables on the left hand side of the assignment. Perhaps one of the unused characters (question mark, say) could be used for this. So if we started with:- longVarName = longVarName + 1 ...we could change it to:- longVarName = ? + 1 ...and then perhaps ?1, ?2, etc for multiple assignments. &. Lua list <[hidden email]> writes: >1) In Lua, contrary to C/C++, assignments are statements but not >expressions. C++ syntax relies heavily on the fact that assignations are >expressions. In Lua you have a single assignment operator, just one, >which is not in the same category at all than binary operators (+ - * / >% .. and or). So adding new assignments operators means: > - having several assignment operators instead of just one (and going >from 1 to 2+ is much more difficult than going from n to n+1) > - introducing ambiguity between assignment and expressions (because += >does both) > - introducing += will encorage people to ask for ++, both prefixed and >suffixed, and ++ will encourage people to ask for assignments to become >expressions, which will completely change the syntax and semantics of >Lua > >2) It also makes it much easier to overide the semantics without >thinking to all corner cases introduced (C++ const-ness and copy >constructor mechanism are in part consequences of the ambiguity >mentionned above). > >3) The very fact that expressions and statements are distinct things in >Lua makes the language much easier to teach to non-programmers, which >constitute a non-marginal part of Lua users. > >I don't know which are the official reasons. The recurrence of that >topic definitively means that we need some online list of frequently >asked and rejected Lua heavy modifications. ##################################################################################### This e-mail message has been scanned for Viruses and Content and cleared by MailMarshal. The Blackpool Sixth Form College. ##################################################################################### ```
Open this post in threaded view
|

## Re: New operators?

 ```On Wed, 2007-04-11 at 20:34 +0100, Andy Stark wrote: > An alternative to assignment operators (+=, etc) might be to have a > shorthand for referring to the variables on the left hand side of the > assignment. Perhaps one of the unused characters (question mark, say) > could be used for this. So if we started with:- > > longVarName = longVarName + 1 > > ...we could change it to:- > > longVarName = ? + 1 > > ...and then perhaps ?1, ?2, etc for multiple assignments. At least two people have suggested this (or something similar) before, and I've always felt that it looks and feels a little bit to "magical" in the Perl sense - certainly the use of a special character. B. ```
Open this post in threaded view
|

## Re: New operators?

 In reply to this post by Andy Stark ```On 4/11/07, Andy Stark <[hidden email]> wrote: ``````An alternative to assignment operators (+=, etc) might be to have a shorthand for referring to the variables on the left hand side of the assignment. Perhaps one of the unused characters (question mark, say) could be used for this. So if we started with:- longVarName = longVarName + 1 ...we could change it to:- longVarName = ? + 1 `````` ...which immediately makes me think of Perl's \$_ (the "it" variable), and I don't think any of us want to go down that road, do we? ;) -- Hisham ```
Open this post in threaded view
|

## Re: New operators?

 In reply to this post by Andy Stark ```When using C(-alike scripting) language(s), I really like the += "feature". ```But I really got that lua gets much more complicated, like Jerome already said. ``` ```Why don't you just use a add function or something like this? Is very little amount of extra letters and keeps everything clear to understand, too. ``` ```Instead of the wanted var1 += newvar1 then you use inc(var1,newvar1) with var1 beeing a call by reference (so after calling, var1 = var1 + newvar1). ``` ```But I must addmit, that I am not that fimilar with possibilities to call by reference with numbers in lua (in a table its a default). ``` Kind regards, Jan (DracoBlue) ___________________________ http://dracoblue.net ```
Open this post in threaded view
|

## Re: New operators?

 In reply to this post by Rob Kendrick ```Lua list <[hidden email]> writes: >On Wed, 2007-04-11 at 20:34 +0100, Andy Stark wrote: >> An alternative to assignment operators (+=, etc) might be to have a >> shorthand for referring to the variables on the left hand side of the >> assignment. >At least two people have suggested this (or something similar) before, >and I've always felt that it looks and feels a little bit to >"magical" >in the Perl sense - certainly the use of a special character. I know what you mean but this isn't quite the same as Perl's special pronoun variables which really are variables in the strict sense (you can assign to them, etc). You could use special variable names like "itself" or something, but they would need to be short names and introducing them to the language would break existing code that used those names. Turning the problem around... would it be possible to modify the expression parsing code to allow something like backreferences in regular expressions? Bracketed sub-expressions could be referred to via a shortcut so you could change:- longVarName = longVarName + 1 ...into \1 = (longVarName) + 1 Or maybe an alias operator that allows you to create temporary local names for variables:- ?x = longVarName?x + 1 -- read longVarName?a as "longVarName which we will call x" I suppose once you created one of these aliases, you could use it on the right hand side of the assignment too. Personally, I don't really have a problem with the existing method of re-typing the variable name, but presumably there is some reason why people keep asking for this. &. ##################################################################################### This e-mail message has been scanned for Viruses and Content and cleared by MailMarshal. The Blackpool Sixth Form College. ##################################################################################### ```
Open this post in threaded view
|

## Re: New operators?

 ```> Or maybe an alias operator that allows you to create temporary local names > for variables:- > > ?x = longVarName?x + 1 -- read longVarName?a as "longVarName which we > will call x" Aliases in the form alias x=longVarName, y=AnotherLongVarName are trivial to implement with token filters (though respecting scopes will need some real work). --lhf ```
Open this post in threaded view
|

## Re: New operators?

 In reply to this post by Andy Stark ```On Wed, Apr 11, 2007 at 08:34:23PM +0100, Andy Stark wrote: > An alternative to assignment operators (+=, etc) might be to have a > shorthand for referring to the variables on the left hand side of the > assignment. Perhaps one of the unused characters (question mark, say) > could be used for this. So if we started with:- > > longVarName = longVarName + 1 > > ...we could change it to:- > > longVarName = ? + 1 This makes me feel like I'm reading Perl code, where everything is a mass of strange, unconventional operators. Inventing new, unfamiliar operators for a language has its place ... but this just feels contrived, where typical += operators are what's really wanted. > ...and then perhaps ?1, ?2, etc for multiple assignments. This is inviting unreadable code, where you have to keep looking back and forth and counting to figure out what each number in an expression means. I've adjusted enough Perl expressions after changing a regexp to call it a maintenance nightmare, too. -- Glenn Maynard ```
Open this post in threaded view
|

## Re: New operators?

 In reply to this post by Andy Stark ```Andy Stark wrote: ``````An alternative to assignment operators (+=, etc) might be to have a shorthand for referring to the variables on the left hand side of the assignment. Perhaps one of the unused characters (question mark, say) could be used for this. So if we started with:- longVarName = longVarName + 1 ...we could change it to:- longVarName = ? + 1 ...and then perhaps ?1, ?2, etc for multiple assignments. `````` Some time ago, I wrote a patch for Lua which does this (except with \$ instead of ?), which I think is floating around in various places (not on LuaPowerPatches, though, because I'm not really sure I like it either.) If you want to play with it (and it comes with absolutely no guarantees), you can find it at: http://primero.ricilake.net/lua/pseudo-5.1.2.patch Note: in a multiple assignment, \$ refers to the matching lhs, and \$i refers to the i'th lhs. I'm not certain that the "matching lhs" rule is correct: it's been suggested that \$ should refer to the list of lhs's, so that you could do a sort of rotate: a[x], a[x+1], a[x+2] = \$3, \$ That indeed might be convenient but right now you'd have to write: a[x], a[x+1], a[x+2] = \$3, \$1, \$2 With this notation, ++ can be expressed almost as concisely: a[x] =\$+ 1 and you can write expressions hard to write in C++, such as: a[x] = 2 * \$ + 1 a[x] = func(\$) etc. It does have a certain something going for it.... ```
Open this post in threaded view
|

## Re: New operators?

 In reply to this post by Andy Stark ```Andy Stark wrote: > An alternative to assignment operators (+=, etc) might be to have a > shorthand for referring to the variables on the left hand side of the > assignment. Perhaps one of the unused characters (question mark, say) > could be used for this. So if we started with:- > > longVarName = longVarName + 1 > > ...we could change it to:- > > longVarName = ? + 1 > > ...and then perhaps ?1, ?2, etc for multiple assignments. Though I don't see this getting in to the core just yet, I must say this is a fascinating approach to the problem! - Peter ```
Open this post in threaded view
|

## Re: New operators?

 In reply to this post by Jerome Vuarand-2 ```On 4/11/07, Jerome Vuarand <[hidden email]> wrote: ``````Here are some very personnal reasons: 1) In Lua, contrary to C/C++, assignments are statements but not expressions. C++ syntax relies heavily on the fact that assignations are expressions. In Lua you have a single assignment operator, just one, which is not in the same category at all than binary operators (+ - * / % .. and or). So adding new assignments operators means: - having several assignment operators instead of just one (and going from 1 to 2+ is much more difficult than going from n to n+1) - introducing ambiguity between assignment and expressions (because += does both) - introducing += will encorage people to ask for ++, both prefixed and suffixed, and ++ will encourage people to ask for assignments to become expressions, which will completely change the syntax and semantics of Lua `````` I would love to see += and its ilk as statements, though it does seem like a lot of new operators, and a nice syntax for the same thing without reusing operators would be nice. I don't really connect assignment-as-expression and ++ with +=. I quite dislike the former. I would love to be able to do this, though: x, y += xOffset, yOffset ```
Open this post in threaded view
|

## Re: New operators?

 In reply to this post by Luiz Henrique de Figueiredo ```Lua list <[hidden email]> writes: >Aliases in the form > alias x=longVarName, y=AnotherLongVarName >are trivial to implement with token filters (though respecting scopes will >need some real work). Do you mean that this would create new variables called x and y in the function where the expression is used? This isn't what I was thinking of, really. I imagined the aliases simply being "local" to the expression or assignment (the leading question mark is to distinguish the symbols from ordinary variables). So you could write:- ?x = longVarName?x + 1 ...but it would be an error to follow this with newVar = ?x * 2 ...on the next line because the ?x only exists for a single expression/assignment. It's a bit like Python's lambda expressions or the DEF FN you used to get in old versions of Basic but the declaration is built into the expression and the "dummy" variable names disappear immediately after the expression is finished. It occurs to me that it might be an advantage to be able to alias values on the left of the assignment too, in cases like:- table.x, table.y = table.y, table.x ...which would become table?a.x, ?a.y, = ?a.y, ?a.x ...a little bit like the swizzling feature in shader languages only more flexible and less concise. &. ##################################################################################### This e-mail message has been scanned for Viruses and Content and cleared by MailMarshal. The Blackpool Sixth Form College. ##################################################################################### ```
Open this post in threaded view
|

## What's up with token filters (Re: New operators?)

 In reply to this post by Glenn Maynard ``` There already is a solution for this, namely token filters. ```Only - they are not mainstream (5.1.2) as of yet, and whether they shall be remains a mystery. ``` ```If the term is new, they allow you to "add on" Lua syntaxes on the fly, by "-lmyfilters" when launching Lua. Without patching. ``` ```Instead of asking for += (which I, too, would like to use) one might re-ask about the status on mainstreaming token filters into Lua? :) ``` -asko Glenn Maynard kirjoitti 12.4.2007 kello 0:37: ``````On Wed, Apr 11, 2007 at 08:34:23PM +0100, Andy Stark wrote: ``````An alternative to assignment operators (+=, etc) might be to have a shorthand for referring to the variables on the left hand side of the assignment. Perhaps one of the unused characters (question mark, say) could be used for this. So if we started with:- longVarName = longVarName + 1 ...we could change it to:- longVarName = ? + 1 `````` This makes me feel like I'm reading Perl code, where everything is a mass of strange, unconventional operators. Inventing new, unfamiliar ```operators for a language has its place ... but this just feels contrived, ```where typical += operators are what's really wanted. ``````...and then perhaps ?1, ?2, etc for multiple assignments. `````` This is inviting unreadable code, where you have to keep looking back and forth and counting to figure out what each number in an expression means. I've adjusted enough Perl expressions after changing a regexp to call it a maintenance nightmare, too. -- Glenn Maynard `````` ```
Open this post in threaded view
|

## Re: What's up with token filters (Re: New operators?)

 ```> one might > re-ask about the status on mainstreaming token filters into Lua? :) No conclusion yet. --lhf ```
Open this post in threaded view
|

## Re: What's up with token filters (Re: New operators?)

 In reply to this post by Asko Kauppi ```On Thu, Apr 12, 2007 at 06:45:02PM +0300, Asko Kauppi wrote: > There already is a solution for this, namely token filters. I don't want to have to learn a new child language when I use Lua in a different place, depending on the little extensions in each case. Adding += to my copy of Lua is not the same as += being added to Lua. Lacking these operators isn't the end of the world. In practice, it means getting in the bad habit of using shorter variable names than I would otherwise, some cumbersome copying and pasting of variable names, and marginally less readable code--but as language warts go, it's small. It just seems like an odd omission from the language ... -- Glenn Maynard ```
Open this post in threaded view
|

## Re: What's up with token filters (Re: New operators?)

 In reply to this post by Asko Kauppi ```> Instead of asking for += (which I, too, would like to use) one might > re-ask about the status on mainstreaming token filters into Lua? :) Actually, quite recently I sent a message about this: http://lua-users.org/lists/lua-l/2007-04/msg00178.html -- Roberto ```
Open this post in threaded view
|

## Re: What's up with token filters (Re: New operators?)

 In reply to this post by Glenn Maynard ```-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Glenn Maynard wrote: [...] > I don't want to have to learn a new child language when I use Lua in a > different place, depending on the little extensions in each case. Adding += > to my copy of Lua is not the same as += being added to Lua. [...] > It > just seems like an odd omission from the language ... The Lua philosphy is that the core language contains just enough language to be useful, and if you want any additional syntactic sugar, you add it to *your own* copy. The fact that each place uses its own dialect is a feature, not a bug. The core language has very little sugar (the only things I can remember offhand are that x.y is x["y"], function foo() becoming foo = function(), and the : operator. Also, adding something like += isn't as simple as it first appears. Remember that the = operator is *not*: lvalue = expression Instead, it's: lvalue, lvalue, ... = expression, expression, ... So if we have a statement like: a, b += 1 ...then what this is actually going to do is to add 1 to a and add nil to b, which will most likely fail. This is not intuitive and you're almost certainly going to get people wanting this special-cased so that 1 gets added to both a and b. That's even *less* intuitive, because it's now inconsistent with =. Even once that's been settled, you now have a primitive operation for 'increment' (and decrement, and self-multiplication, and self-division, etc). Would it not make sense to add metatable entries for these? That would allow such things as: local vector = Vector.new(1, 2) vector *= 1.5 -- scale vector in place Logically you do, because it adds consistency to the language, but now you've just doubled the number of metatable operations, which has lots of knock-on effects on size and speed. Basically, this kind of extension adds convenience rather than functionality, and as such I do not believe it belongs in the core language due to the additional complexity the extension requires. (In fact, I'd argue against the 'function foo()' syntax, too, but it's too late now for that.) This sort of thing is, IMO, better suited for a precompilation step or a local modification, than something that has to be designed so that it suits everyone. - -- âââ ïïïïïïïïïïïïïï âââ http://www.cowlark.com âââââââââââââââââââ â "Thou who might be our Father, who perhaps may be in Heaven, hallowed be â Thy Name, if Name Thou hast and any desire to see it hallowed..." --- â _Creatures of Light and Darkness_ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGHnUaf9E0noFvlzgRAu5HAJ9rDL9rS1aJ1jx+/fB2CdUN5nQnSQCfbO3x IOlS1OXfaXONyj7SnQAEL9M= =oVnk -----END PGP SIGNATURE----- ```
 ```David Given wrote: > Basically, this kind of extension adds convenience rather than > functionality, and as such I do not believe it belongs in the core > language due to the additional complexity the extension requires. (In > fact, I'd argue against the 'function foo()' syntax, too, but it's > too late now for that.) This sort of thing is, IMO, better suited for > a precompilation step or a local modification, than something that > has to be designed so that it suits everyone. That's precisely the purpose of the idea of integrating token filters in stock Lua distribution. People want syntactic sugars but don't want to maintain a patch of the core Lua sources. So they ask the syntactic sugar to be put directly in official distribution. With token filters, syntactic sugars become data-driven, and people could easily add them to stock Lua, without having to worry about maintenance (maintaining a module is much easier than maintaining a patch of the Lua core). They would also become easy to distribute and combine, whereas a patch is not. To quote you, token filter adds the "features" necessary to allow everyone to add "convenience" *easily* on their own copy of Lua (patching Lua core is *not* easy). And token filters are well designed enough to suit almost everyone. That's also the case of metalua, though in a heavier way. ```