+=

classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|

+=

Steve Dekorte-4
Anyone considered adding a += (and -=, /=. *=) operator to lua?

I notice I have a lot of code that does stuff like:

self.x = self.x + dx

I'm guessing that:

self.x += dx 

could be compiled to something with fewer table look-ups and instructions(?)

Steve

Reply | Threaded
Open this post in threaded view
|

Re: +=

Luiz Henrique de Figueiredo
>Anyone considered adding a += (and -=, /=. *=) operator to lua?

Yes, I think this has been discussed before.

>I notice I have a lot of code that does stuff like:
>
>self.x = self.x + dx
>
>I'm guessing that:
>
>self.x += dx 
>
>could be compiled to something with fewer table look-ups and instructions(?)

I doubt it, because of the possibility of tag methods coming into action.

Right now, the bytecode for "self.x = self.x + dx" is

  GETGLOBAL       0       ; self
  PUSHSTRING      1       ; "x"
  GETGLOBAL       0       ; self
  GETDOTTED       1       ; x
  GETGLOBAL       2       ; dx
  ADD
  SETTABLE        3 3
  END

Except for the two GETGLOBAL for self, I don't see how this can be shortened.
--lhf

Reply | Threaded
Open this post in threaded view
|

RE: +=

Pete Gardner
In reply to this post by Steve Dekorte-4
> 
> >Anyone considered adding a += (and -=, /=. *=) operator to lua?
> 
> Yes, I think this has been discussed before.
> 

I would just as soon use  
	value1.add(value2)  
instead of 
	value1+=value2

Not much more typing, and it's still pretty clear.  Does Lua support that
right now?  (Newbie, here.)

However,
	value1.add(value2.add(value3).sub(value4.mult(value5)))
Could get confusing, though...


Reply | Threaded
Open this post in threaded view
|

RE: +=

Steve Dekorte-4
In reply to this post by Steve Dekorte-4
Pete Gardner wrote:
> I would just as soon use   
> 	value1.add(value2)   
> instead of  
> 	value1+=value2 
>  
> Not much more typing, and it's still pretty clear.  Does Lua support that 
> right now?  (Newbie, here.) 

Yeah - you can do it using the tag method for lookups on numbers.

Steve

Reply | Threaded
Open this post in threaded view
|

Re: +=

Erik Hougaard
In reply to this post by Luiz Henrique de Figueiredo
----- Original Message -----
> Except for the two GETGLOBAL for self, I don't see how this can be
shortened.

I think the primary issue here is the way the source looks.. If it comes
down to speed I dont think that x=x+1 will be the critical thing to look at
:-)

/Erik


Reply | Threaded
Open this post in threaded view
|

Re: +=

Steve Dekorte-6

Erik Hougaard wrote:
I think the primary issue here is the way the source looks..

I'm actually only concerned about the speed.

If it comes
down to speed I dont think that x=x+1 will be the critical thing to look at

Well, any operation becomes critical if placed in a tight loop.
And adding to a value is actually a pretty common operation in many loops.

Steve

Reply | Threaded
Open this post in threaded view
|

Re: +=

Carlos Cardoso
In reply to this post by Erik Hougaard
x = x + 1 is sooo BASIC. As a former ZX-Spectrum owner, I do not dislike
it a lot. The only problem is a psichological one. In my mind, x++ works
faster, even KNOWING it's not true when it compiles.



On Wed, 28 Mar 2001 09:25:39 +0200
[hidden email] (Erik Hougaard) wrote:

> ----- Original Message -----
> > Except for the two GETGLOBAL for self, I don't see how this can be
> shortened.
> 
> I think the primary issue here is the way the source looks.. If it comes
> down to speed I dont think that x=x+1 will be the critical thing to look at
> :-)
> 
> /Erik
> 



Atenciosamente,

Carlos Cardoso
[hidden email]

-------------------------------------
Hands - o site brasileiro que coloca
as informações na palma de suas mãos.
       http://www.hands.com.br
-------------------------------------
HANDS - Eleita melhor empresa de Internet na
categoria serviços na Fenasoft  2000 .


Reply | Threaded
Open this post in threaded view
|

Re: +=

Magnus Lie Hetland
> x = x + 1 is sooo BASIC. As a former ZX-Spectrum owner, I do not dislike
> it a lot. The only problem is a psichological one. In my mind, x++ works
> faster, even KNOWING it's not true when it compiles.

Eww... State change is so crude. <wink>

--

  Magnus Lie Hetland         http://www.hetland.org

 "Reality is that which, when you stop believing in
  it, doesn't go away."           -- Philip K. Dick



Reply | Threaded
Open this post in threaded view
|

Re: +=

Jason Clow
In reply to this post by Steve Dekorte-4
How would one go about implementing operators such as +=, -=, ++, etc? I use x = x + something_else quite a lot, and having x += something_else would make my code look so much cleaner, imho. Is there a way to do it with Lua code (like tag methods), or will it have to be added to the parser?

==
|    ._  _   Lune MUW Server
|_(_)| )(/_  http://lune.sourceforge.net/

_____________________________________________________________


Reply | Threaded
Open this post in threaded view
|

Doing it in Lua (was Re: +=)

Magnus Lie Hetland
----- Original Message ----- 
From: "Jason Clow" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Wednesday, March 28, 2001 5:56 PM
Subject: Re: +=


> How would one go about implementing operators such as
> +=, -=, ++, etc? I use x = x + something_else quite a lot,
> and having x += something_else would make my code look so
> much cleaner, imho. Is there a way to do it with Lua code
> (like tag methods), or will it have to be added to the parser?

Can't you do something like x:add(something)? And then implement
the add-thing with a tag method or something. You could have
x:multiply(something) etc. as well...

Just a thought.

--

  Magnus Lie Hetland         http://www.hetland.org

 "Reality is that which, when you stop believing in
  it, doesn't go away."           -- Philip K. Dick



Reply | Threaded
Open this post in threaded view
|

Re: +=

Carlos Cardoso
In reply to this post by Magnus Lie Hetland
Life is not fair. As a Perl lover, I hardly can't live without
constructions like "unless (foo) {bar} "

BUT the point is: If we adapt LUA to serve OUR individual tastes, it
will grow fast, slow and useless. 


On Wed, 28 Mar 2001 17:09:33 +0200
"Magnus Lie Hetland" <[hidden email]> wrote:

> > x = x + 1 is sooo BASIC. As a former ZX-Spectrum owner, I do not dislike
> > it a lot. The only problem is a psichological one. In my mind, x++ works
> > faster, even KNOWING it's not true when it compiles.
> 
> Eww... State change is so crude. <wink>
> 
> --
> 
>   Magnus Lie Hetland         http://www.hetland.org
> 
>  "Reality is that which, when you stop believing in
>   it, doesn't go away."           -- Philip K. Dick
> 
> 



Atenciosamente,

Carlos Cardoso
[hidden email]

-------------------------------------
Hands - o site brasileiro que coloca
as informações na palma de suas mãos.
       http://www.hands.com.br
-------------------------------------
HANDS - Eleita melhor empresa de Internet na
categoria serviços na Fenasoft  2000 .


Reply | Threaded
Open this post in threaded view
|

Re: +=

Eduardo Ochs-2
In reply to this post by Steve Dekorte-4
About "+=", "while (foo(); x = bar()) ... end", etc:

What about resurrecting the yacc-based parser, adapting it to the new
syntax, and including it in Lua-4.1, even if the default would be to
not even compile it? Then it would be easier for users to experiment
with changes on the syntax...

Other ideas: one could load a library and replace the default "dofile"
and "dostring" functions on a certain Lua interpreter; one could write
in standard Lua a program that would work like the functions
"handle_argv" and "main" in src/lua/lua.c, but using a parser loaded
on the fly... etc, etc.

I think that Lua is a fantastic language, but its syntax is sometimes
too verbose for people (like me!) who would like to use it for
one-shot programs, not only for "serious stuff" or for (there's a lot
of irony here, of course) programs that have to be maintainable by
non-programmers later. I guess that one of the main reasons to keep it
so simple is to make it easier to construct metaprogramming tools, but
these aren't ready yet...

BTW, here's a link to a very interesting paper on metaprogramming:
"Building Source-Code Processors for Icon Programs", by Ralph E.
Griswold,

  <http://www.cs.arizona.edu/icon/docs/ipd263.htm>.

Cheers,
  Eduardo Ochs
  http://angg.twu.net/
  [hidden email]
  [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: +=

Carlos Cardoso
> I think that Lua is a fantastic language, but its syntax is sometimes
> too verbose for people (like me!) who would like to use it for
> one-shot programs, not only for "serious stuff" or for (there's a lot
> of irony here, of course) programs that have to be maintainable by
> non-programmers later. I guess that one of the main reasons to keep it
> so simple is to make it easier to construct metaprogramming tools, but
> these aren't ready yet...

Fascinating. 

Your statement goes against everything I believed about part-time programmers
(without the <IRONY> tags, of course).

They usually like verbose languages, like Javascript, and don't want to
go deep in logical constructions or sintax black magic. 

Now, about "programs maintainable by non-programmers"... is it possible?
All the cases I know ended with lots of useless patchworked code and a
caffeine-induced programmer working all night long to fix the mess. 


Atenciosamente,

Carlos Cardoso
[hidden email]

-------------------------------------
Hands - o site brasileiro que coloca
as informações na palma de suas mãos.
       http://www.hands.com.br
-------------------------------------
HANDS - Eleita melhor empresa de Internet na
categoria serviços na Fenasoft  2000 .


Reply | Threaded
Open this post in threaded view
|

Re: +=

Luiz Henrique de Figueiredo
In reply to this post by Steve Dekorte-4
>What about resurrecting the yacc-based parser, adapting it to the new
>syntax, and including it in Lua-4.1, even if the default would be to
>not even compile it? Then it would be easier for users to experiment
>with changes on the syntax...

I thought about this. It would be convenient for people wishing to extend 
Lua's syntax to make sure they would not be breaking anything. but we 
most certainly do not want to encourage people to create Lua derivatives,
and still want to call it Lua. So, the yacc file is not going to happen
(plus it'd be a lot of work.)
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: +=

Carlos Cardoso
> I thought about this. It would be convenient for people wishing to extend 
> Lua's syntax to make sure they would not be breaking anything. but we 
> most certainly do not want to encourage people to create Lua derivatives,
> and still want to call it Lua. So, the yacc file is not going to happen
> (plus it'd be a lot of work.)
> --lhf

Agreed. As long as it makes sense to create new functions to explore a
device's capabilities, makes no sense to have incompatible cores. 

I would love to create an "unless" statement, and other (tongue in
cheek)usefull functions, but what's the point, if it makes my code
unreadable to everyone else?

I am not THAT selfish ;)



Atenciosamente,

Carlos Cardoso
[hidden email]

-------------------------------------
Hands - o site brasileiro que coloca
as informações na palma de suas mãos.
       http://www.hands.com.br
-------------------------------------
HANDS - Eleita melhor empresa de Internet na
categoria serviços na Fenasoft  2000 .


Reply | Threaded
Open this post in threaded view
|

use stric?

Carlos Cardoso
Sorry for a semi-desperated newbie question but...

Is there a way to Lua DEMAND variable declaration, like C?

Sometimes a simple type is enough to ruin an entire day..





Atenciosamente,

Carlos Cardoso
[hidden email]

-------------------------------------
Hands - o site brasileiro que coloca
as informações na palma de suas mãos.
       http://www.hands.com.br
-------------------------------------
HANDS - Eleita melhor empresa de Internet na
categoria serviços na Fenasoft  2000 .


Reply | Threaded
Open this post in threaded view
|

Re: use stric?

Luiz Henrique de Figueiredo
>Is there a way to Lua DEMAND variable declaration, like C?
>
>Sometimes a simple type is enough to ruin an entire day..

See FAQ 3.1 - How do I declare variables?
http://www.tecgraf.puc-rio.br/lua/faq.html#3.1

--lhf

Reply | Threaded
Open this post in threaded view
|

Re: use stric?

Carlos Cardoso
It says "rawgetglobal" is deprecated, but looks like a nice and elegant
solution. Thanks a lot, I deserved the RTFM ;)



On Wed, 28 Mar 2001 17:07:59 -0300 (EST)
Luiz Henrique de Figueiredo <[hidden email]> wrote:

> >Is there a way to Lua DEMAND variable declaration, like C?
> >
> >Sometimes a simple type is enough to ruin an entire day..
> 
> See FAQ 3.1 - How do I declare variables?
> http://www.tecgraf.puc-rio.br/lua/faq.html#3.1
> 
> --lhf



Atenciosamente,

Carlos Cardoso
[hidden email]

-------------------------------------
Hands - o site brasileiro que coloca
as informações na palma de suas mãos.
       http://www.hands.com.br
-------------------------------------
HANDS - Eleita melhor empresa de Internet na
categoria serviços na Fenasoft  2000 .


Reply | Threaded
Open this post in threaded view
|

Re: +=

Michael T. Richter-2
In reply to this post by Carlos Cardoso
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> BUT the point is: If we adapt LUA to serve OUR individual tastes, it
> will grow fast, slow and useless. 

Like every committee or fan-base-"enhanced" language in history.

Remember when Forth was small and elegant?

- --
Michael T. Richter
"Be seeing you."

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQA/AwUBOsJWUbTM3QkE7U/oEQLUPQCgtqxHHM+wb1g1MdnjbuypzNI9M4YAoNLQ
DVnb/9qZoLr58mrKwD5IKDJf
=sJUs
-----END PGP SIGNATURE-----



Reply | Threaded
Open this post in threaded view
|

Re: use stric?

Luiz Henrique de Figueiredo
In reply to this post by Carlos Cardoso
>It says "rawgetglobal" is deprecated, but looks like a nice and elegant
>solution. Thanks a lot, I deserved the RTFM ;)

The FAQ needs updating badly. I'm sorry about this.

Here is "rawgetglobal":

function rawgetglobal(n) return rawget(globals(),n) end

--lhf

123