list iteration for statement

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

list iteration for statement

John Belmonte-2
I've been thinking it would be nice to have another form of the for loop on
top of two we have now, for iterating lists:

    for val in list do
        print(val)
    end

The equivalent in the Lua as it is now:

    for i = 1, getn(list) do
        local val = list[i]
        print(val)
    end

Such iteration (where the list is not modified) is very common.  My argument
for adding this new form is that it's more terse, less error prone
(forgetting the local qualifier, etc), and faster if the list happens to be
a global.

Any thoughts?

-John



Reply | Threaded
Open this post in threaded view
|

RE: list iteration for statement

Philippe Lhoste
John Belmonte wrote:
> I've been thinking it would be nice to have another form of the
> for loop on
> top of two we have now, for iterating lists:
>
>     for val in list do
>         print(val)
>     end
>
> The equivalent in the Lua as it is now:
>
>     for i = 1, getn(list) do
>         local val = list[i]
>         print(val)
>     end
>
> Such iteration (where the list is not modified) is very common.
> My argument
> for adding this new form is that it's more terse, less error prone
> (forgetting the local qualifier, etc), and faster if the list
> happens to be
> a global.
>
> Any thoughts?

Sorry if I don't answer correctly to your request, but I believe Lua already
have a mechanism for this.
Excerpt from the manual:

>>>
foreach (table, func)
Executes the given func over all elements of table. For each element, the
function is called with the index and respective value as arguments. If the
function returns any non-nil value, then the loop is broken, and this value
is returned as the final value of foreach. This function could be defined in
Lua:
       function foreach (t, f)
         for i, v in t do
           local res = f(i, v)
           if res then return res end
         end
       end

The behavior of foreach is undefined if you change the table t during the
traversal.

foreachi (table, func)
Executes the given func over the numerical indices of table. For each index,
the function is called with the index and respective value as arguments.
Indices are visited in sequential order, from 1 to n, where n is the result
of getn(table) (see Section 6.1). If the function returns any non-nil value,
then the loop is broken, and this value is returned as the final value of
foreachi. This function could be defined in Lua:
       function foreachi (t, f)
         for i=1,getn(t) do
           local res = f(i, t[i])
           if res then return res end
         end
       end
<<<

Regards.

--._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
--´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`--


Reply | Threaded
Open this post in threaded view
|

Re: list iteration for statement

John Belmonte-2
Philippe Lhoste wrote:
> Sorry if I don't answer correctly to your request, but I believe Lua
already
> have a mechanism for this.
>
> foreach (table, func)
> foreachi (table, func)

Sorry, I should have addressed these library functions in my post.  Well, if
foreach() is so great, why do we have a special for construct to do the same
thing?  Remember that the for command was created after these functions
already existed.  I'll bet that since for loops were introduced as a way to
iterate tables, most of us don't use foreach() anymore.  Having to create
function objects can sometimes make code hard to follow.   So since there is
a form of for matching foreach(), why not foreachi() too?

For comparison, here is my example again using foreachi.  It's not bad in
the case of a one-statement function, but for larger functions it becomes
less readable that using a for construct.

    foreachi(list, function(i, val) print(val) end)


-John



Reply | Threaded
Open this post in threaded view
|

Re: list iteration for statement

Adolf Mathias
John Belmonte wrote:
> 
> Philippe Lhoste wrote:
> > Sorry if I don't answer correctly to your request, but I believe Lua
> already
> > have a mechanism for this.
> >
> > foreach (table, func)
> > foreachi (table, func)
> 
> Sorry, I should have addressed these library functions in my post.  Well, if
> foreach() is so great, why do we have a special for construct to do the same
> thing?  Remember that the for command was created after these functions
> already existed.  I'll bet that since for loops were introduced as a way to
> iterate tables, most of us don't use foreach() anymore.  Having to create
> function objects can sometimes make code hard to follow.   So since there is
> a form of for matching foreach(), why not foreachi() too?

And while we're at it, I'd really love a "next" tag method (maybe also
"nexti") that allows the construction of generic iterators for user
types. A for/foreach function should then use the respective tag
methods...

Dolfi

- 
Adolf Mathias              EMail: dolfi at zkm dot de  Web: www.zkm.de
|||| / |< |||                 ZKM Basic Research - Grundlagenforschung
P.B. 6919 D-76049 Karlsruhe, Germany; fon +49 721-8100-1511, fax -1509

Reply | Threaded
Open this post in threaded view
|

RE: list iteration for statement

Eric Ries
In reply to this post by John Belmonte-2
Perhaps this is too kludgy, but we could always add
for val in list do
	X
end
as syntactic sugar for
foreachi( list, function(i,val) X end )

It would make reading the code for that functionality cleaner, so it gets my
vote.

Eric

> -----Original Message-----
> From: [hidden email]
> [[hidden email] Behalf Of John Belmonte
> Sent: Thursday, April 26, 2001 6:07 AM
> To: Multiple recipients of list
> Subject: Re: list iteration for statement
>
>
> Philippe Lhoste wrote:
> > Sorry if I don't answer correctly to your request, but I believe Lua
> already
> > have a mechanism for this.
> >
> > foreach (table, func)
> > foreachi (table, func)
>
> Sorry, I should have addressed these library functions in my
> post.  Well, if
> foreach() is so great, why do we have a special for construct to
> do the same
> thing?  Remember that the for command was created after these functions
> already existed.  I'll bet that since for loops were introduced
> as a way to
> iterate tables, most of us don't use foreach() anymore.  Having to create
> function objects can sometimes make code hard to follow.   So
> since there is
> a form of for matching foreach(), why not foreachi() too?
>
> For comparison, here is my example again using foreachi.  It's not bad in
> the case of a one-statement function, but for larger functions it becomes
> less readable that using a for construct.
>
>     foreachi(list, function(i, val) print(val) end)
>
>
> -John
>


Reply | Threaded
Open this post in threaded view
|

RE: list iteration for statement

Philippe Lhoste
In reply to this post by John Belmonte-2
John Belmonte wrote:
> Philippe Lhoste wrote:
> > Sorry if I don't answer correctly to your request, but I believe Lua
> already
> > have a mechanism for this.
> >
> > foreach (table, func)
> > foreachi (table, func)
>
> Sorry, I should have addressed these library functions in my
> post.  Well, if
> foreach() is so great, why do we have a special for construct to
> do the same
> thing?  Remember that the for command was created after these functions
> already existed.  I'll bet that since for loops were introduced
> as a way to
> iterate tables, most of us don't use foreach() anymore.  Having to create
> function objects can sometimes make code hard to follow.   So
> since there is
> a form of for matching foreach(), why not foreachi() too?
>
> For comparison, here is my example again using foreachi.  It's not bad in
> the case of a one-statement function, but for larger functions it becomes
> less readable that using a for construct.
>
>     foreachi(list, function(i, val) print(val) end)

OK. But actually, it wasn't even these functions I was thinking of, it was
the construct:
>>>
The table for statement traverses all pairs (index,value) of a given table.
It has the following syntax:

       stat ::= for name `,' name in exp1 do block end

A for statement like
       for index, value in exp do block end
<<<

I am probably thick (still a newbie here, lurks a lot, doesn't codes much
Lua yet), but how this differ deeply from your:
>>>
    for val in list do
        print(val)
    end
<<<
?
I feel I am missing something here, as I am alone to ask this, but you seems
patient with lusers... (a word I learned here :-)
Perhaps your lists are not tables?

Regards.

--._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
--´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`--


Reply | Threaded
Open this post in threaded view
|

Re: list iteration for statement

John Belmonte-2
Philippe Lhoste wrote:
> A for statement like
>        for index, value in exp do block end
>
> I am probably thick (still a newbie here, lurks a lot, doesn't codes much
> Lua yet), but how this differ deeply from your:
> >>>
>     for val in list do
>         print(val)
>     end
> <<<

Table iteration using "for index, value" does not guarantee any ordering,
which is often required for lists.  If order is not important it's possible
to use "for index, value" on a list, but be careful about the n field that
may be inserted by some library functions which would cause the iteration to
break.

-John



Reply | Threaded
Open this post in threaded view
|

Re: list iteration for statement

David Jeske-3
In reply to this post by Adolf Mathias
On Thu, Apr 26, 2001 at 03:01:08PM +0200, Adolf Mathias wrote:
> And while we're at it, I'd really love a "next" tag method (maybe
> also "nexti") that allows the construction of generic iterators for
> user types. A for/foreach function should then use the respective
> tag methods...

This would be a nice addition, because it would allow you to construct
native-looking list or array datatypes (which can be iterated
through). However, if I remember correctly from when I suggested this
it turns out to be pretty tricky.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: list iteration for statement

Edgar Toernig
In reply to this post by John Belmonte-2
John Belmonte wrote:
> 
>     for val in list do
>         print(val)
>     end
>
> My argument for adding this new form is that it's more terse, less
> error prone (forgetting the local qualifier, etc), and faster if the
> list happens to be a global.

IMHO the most useful feature of it would be that list is only evaluated
once.  You may iterate for example over function results without a lot
of hassle:

	for key in sorted(table) do ... end
or
	for field in split(string, ":") do ... end
or simply:
	for x in { "foo1", "foo2", "bar", "baz" } do ... end

Ciao, ET.


PS: Has someone an idea for an alternative syntax?  It's so similar
to the regular unordered "for i,v in" loop.  I would prefer a syntax
that makes it more obvious that it is an ordered loop and not just
the regular one without the 'v' var.


Reply | Threaded
Open this post in threaded view
|

Re: list iteration for statement

Nick Trout-2
>>for x in { "foo1", "foo2", "bar", "baz" } do ... end
Ciao, ET.
>>PS: Has someone an idea for an alternative syntax?  It's so similar
to the regular unordered "for i,v in" loop.  I would prefer a syntax
that makes it more obvious that it is an ordered loop and not just
the regular one without the 'v' var.

I was thinking that as well. Could you not have

for [i,]v in list do blah end

since i,v are not optional?

N


Reply | Threaded
Open this post in threaded view
|

toLua 4.0a improvements

Eric Ries
Does anybody know what the current state of toLua development is? I've found
several bugs but have found it more convenient to implement fixes in perl
than in Lua, and so have created a perl frontend that adds some features to
toLua and corrects a few bugs.

For those that are interested, this tool parses .h and .cpp files directly,
produces a temporarr toLua "package" file, runs toLua on that file, and then
(optionally) deletes the intermediate file. If anyone is interested in
seeing/using this tool, let me know.

Hopefully, some of this work can be folded into toLua itself, which is why
I'm curious about the progress of toLua 4.0.

Thanks,

Eric


Reply | Threaded
Open this post in threaded view
|

Re: toLua 4.0a improvements

Nick Trout-2
>>Does anybody know what the current state of toLua development is? I've
found
several bugs but have found it more convenient to implement fixes in perl
than in Lua, and so have created a perl frontend that adds some features to
toLua and corrects a few bugs.
For those that are interested, this tool parses .h and .cpp files directly,
produces a temporarr toLua "package" file, runs toLua on that file, and then
(optionally) deletes the intermediate file. If anyone is interested in
seeing/using this tool, let me know.


I've got one written in Python if anyone would like that :-D Its scans
headers, "cleans" your classes and writes a pkg file. But, too be honest I
found its just as quick to maintain the pkg file yourself and then you can
implement any workarounds easier (eg. enums in classes, renaming etc)

Are you sure you've found bugs in toLua? Usually you just have to find a way
to work round something. What problems have you had?

Regards,
Nick


Reply | Threaded
Open this post in threaded view
|

RE: toLua 4.0a improvements

Eric Ries
Agreed, although it depends on what you count as bugs. toLua is very
amenable to workaroudns :) Mainly I have found workarounds for most of my
issues by having perl modify the package file and/or perform various
search/replaces on toLua's output.

Because I am working with a very large project (literally thousands of
header files), I can't afford to maintain individual package files :)

Here are a few examples:

toLua input
1. toLua misinterprets char const * but handles const char * correctly
2. toLua cannot handle unions within structs, but works fine if you remove
the union keyword and associated braces
3. toLua cannot handle regular unions, so they have to be removed, etc.

toLua output
1. toLua doesn't convert enumerated types correctly (although this is not
really toLua's fault, since it doesn't deal with enumerated types
explicitly), so we have to cast them to int first.
2. MS VC++ doesn't like the way toLua handles bool values, so have to change
	foo = (bool) (tolua_getbool(..));
to
	foo = (tolua_getbool(..) != 0);

I also use the perl script to manage all the tolua_X_open/close functions,
so that they are called (in the right order) automatically at runtime.

Eric

> -----Original Message-----
> From: [hidden email]
> [[hidden email] Behalf Of Nick Trout
> Sent: Friday, April 27, 2001 1:11 PM
> To: Multiple recipients of list
> Subject: Re: toLua 4.0a improvements
>
>
> >>Does anybody know what the current state of toLua development is? I've
> found
> several bugs but have found it more convenient to implement fixes in perl
> than in Lua, and so have created a perl frontend that adds some
> features to
> toLua and corrects a few bugs.
> For those that are interested, this tool parses .h and .cpp files
> directly,
> produces a temporarr toLua "package" file, runs toLua on that
> file, and then
> (optionally) deletes the intermediate file. If anyone is interested in
> seeing/using this tool, let me know.
>
>
> I've got one written in Python if anyone would like that :-D Its scans
> headers, "cleans" your classes and writes a pkg file. But, too be honest I
> found its just as quick to maintain the pkg file yourself and then you can
> implement any workarounds easier (eg. enums in classes, renaming etc)
>
> Are you sure you've found bugs in toLua? Usually you just have to
> find a way
> to work round something. What problems have you had?
>
> Regards,
> Nick


Reply | Threaded
Open this post in threaded view
|

Re: toLua 4.0a improvements

Waldemar Celes
In reply to this post by Nick Trout-2

> >>Does anybody know what the current state of toLua development is?

the current available version is still tolua 4.0a.
I haven't realeased the final 4.0 version because Lua 4.1 will
bring features that will change the way tolua binds the code
(basically allowing tags to be identified by names and checking
userdata equality based solely on its address).
I intend to release tolua4.0, still based on Lua4.0, but already designed
for the new Lua features. I hope I can release it in the next two/three weeks.
Sorry for such a delay.

> Are you sure you've found bugs in toLua? Usually you just have to find a way
> to work round something. What problems have you had?

I'd like to know more about these bugs too.

-- waldemar



Reply | Threaded
Open this post in threaded view
|

Re: list iteration for statement

Reuben Thomas-4
In reply to this post by John Belmonte-2
> already existed.  I'll bet that since for loops were introduced as a way to
> iterate tables, most of us don't use foreach() anymore.

I've only used Lua 4.0, and I use foreach quite a lot in my utility code
(general-purpose routines that iterate over a list and do simple things like
list concatenation, applying a function to each element of a list &c. i.e.
simple functional things. On the other hand, whenever I'm doing more to a
list, I do tend to use for, but only because upvalues are so clumsy.
With proper lexical scoping, I would probably use them more often.

-- 
http://sc3d.org/rrt/ | plagiarism, n.  the mind burgles



Reply | Threaded
Open this post in threaded view
|

minor 4.1 suggestions (was Re: list iteration for statement)

John Belmonte-2
In reply to this post by John Belmonte-2
>     for val in list do
>         print(val)
>     end

While peeking around at the Lua code relating to implementing this, I ran
across a few issues I'd like to see cleaned up for 4.1 (regardless of
implementing the new for form):

    * misnamed functions - Functions related to table iteration are misnamed
using "list" (function forlist etc) in the code.  This for form is clearly
not iterating over a list, and it's going to cause confusion if list
iteration was ever added in the future.  The opcodes are also misnamed
(LFORLOOP etc.) but I suspect changing those would be more headache than
it's worth.

    * "in" allowed as identifier - The parser should give a warning when in
is used as an identifier, so that someday it can be made a "real" keyword
without breaking everyone's code.

-John



Reply | Threaded
Open this post in threaded view
|

Lua on the podium again :-)

Erik Hougaard
In reply to this post by Eric Ries
This years Danish RoboCup has just finished and once again "Crazy Ivan" was
the winner. And once again our robot was running Lua (This time 4.0).

This Lua has been changed to support integers only and to run in a diskless
environment and to communicate with the specialized hardware. The CPU
running Lua is a Motorola Coldfire 5206e

Now off to celebrate :-)

/Erik


Reply | Threaded
Open this post in threaded view
|

RE: Lua on the podium again :-)

Ashley Fryer-2
Congratulations to you and your team, Erik!

Now we can have a new slogan:

  Lua: Our Robot Can Beat Your Robot!

> -----Original Message-----
> From: Erik Hougaard
> Sent: Wednesday, May 02, 2001 7:06 AM
> 
> This years Danish RoboCup has just finished and once again "Crazy 
> Ivan" was
> the winner. And once again our robot was running Lua (This time 4.0).




Reply | Threaded
Open this post in threaded view
|

Re: toLua 4.0a improvements

Nick Trout-2
In reply to this post by Eric Ries
>>From: Eric Ries
>>toLua output
>>1. toLua doesn't convert enumerated types correctly (although this is not
really toLua's fault, since it doesn't deal with enumerated types
explicitly), so we have to cast them to int first.

I assume you're having problems accessing enumeration in classes? I got
round this by doing:

In pkg:
$#define WIDGET_STATE WidgetBehaviourNode::STATE

typedef enum {
 WidgetBehaviourNode::NONE @ STATE_NONE     // etc
}WIDGET_STATE;

class WidgetBehaviourNode
{
 void setState(WIDGET_STATE s);
};

class Other
{
    void something(WIDGET_STATE s);  // which I have trouble with without
workaround.
}

So you have to bodge in another type to access enums in other classes.

>>2. MS VC++ doesn't like the way toLua handles bool values, so have to
change
foo = (bool) (tolua_getbool(..));
to
foo = (tolua_getbool(..) != 0);

Yep - I would like this changed as well please.

>>toLua input
1. toLua misinterprets char const * but handles const char * correctly
2. toLua cannot handle unions within structs, but works fine if you remove
the union keyword and associated braces
3. toLua cannot handle regular unions, so they have to-be removed, etc.

Havent encountered the above. ie. have no unions!





Reply | Threaded
Open this post in threaded view
|

RE: toLua 4.0a improvements

Eric Ries
> -----Original Message-----
> From: [hidden email]
> [[hidden email] Behalf Of Nick Trout
> Sent: Wednesday, May 02, 2001 12:18 PM
> To: Multiple recipients of list
> Subject: Re: toLua 4.0a improvements
>
>
>
> >>From: Eric Ries
> >>toLua output
> >>1. toLua doesn't convert enumerated types correctly (although
> this is not
> really toLua's fault, since it doesn't deal with enumerated types
> explicitly), so we have to cast them to int first.
>
> I assume you're having problems accessing enumeration in classes? I got
> round this by doing:

Actually, although I have also encountered the problem you describe, I was
referring to this output from toLua:

MyEnumType tolua_var_1 = ((MyEnumType) tolua_getnumber(tolua_S,2,0));

needs to be:

MyEnumType tolua_var_1 = ((MyEnumType)(int)  tolua_getnumber(tolua_S,2,0));

> >>2. MS VC++ doesn't like the way toLua handles bool values, so have to
> change
> foo = (bool) (tolua_getbool(..));
> to
> foo = (tolua_getbool(..) != 0);
>
> Yep - I would like this changed as well please.

I'm attaching my toLuaFrontend perl script (for reals this time - last time
I forgot to actually attach it). Let me know if you find it useful.

Eric

Attachment: toLuaFrontend.pl
Description: Binary data

12