New operators?

classic Classic list List threaded Threaded
66 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

New operators?

Eike Decker-2
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

Reply | Threaded
Open this post in threaded view
|

Re: New operators?

Stefan Sandberg
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..


Reply | Threaded
Open this post in threaded view
|

RE: New operators?

Jerome Vuarand-2
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.


Reply | Threaded
Open this post in threaded view
|

Re: New operators?

Andy Stark
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.
#####################################################################################

Reply | Threaded
Open this post in threaded view
|

Re: New operators?

Rob Kendrick
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.


Reply | Threaded
Open this post in threaded view
|

Re: New operators?

Hisham Muhammad
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

Reply | Threaded
Open this post in threaded view
|

Re: New operators?

DracoBlue
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


Reply | Threaded
Open this post in threaded view
|

Re: New operators?

Andy Stark
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.
#####################################################################################

Reply | Threaded
Open this post in threaded view
|

Re: New operators?

Luiz Henrique de Figueiredo
> 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

Reply | Threaded
Open this post in threaded view
|

Re: New operators?

Glenn Maynard
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

Reply | Threaded
Open this post in threaded view
|

Re: New operators?

Rici Lake-2
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....

Reply | Threaded
Open this post in threaded view
|

Re: New operators?

Peter Odding
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

Reply | Threaded
Open this post in threaded view
|

Re: New operators?

John Calsbeek
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

Reply | Threaded
Open this post in threaded view
|

Re: New operators?

Andy Stark
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.
#####################################################################################

Reply | Threaded
Open this post in threaded view
|

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

Asko Kauppi
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


Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
> one might  
> re-ask about the status on mainstreaming token filters into Lua?  :)

No conclusion yet.
--lhf

Reply | Threaded
Open this post in threaded view
|

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

Glenn Maynard
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

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
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

Reply | Threaded
Open this post in threaded view
|

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

David Given
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-----


Reply | Threaded
Open this post in threaded view
|

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

Jerome Vuarand-2
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.


1234