list iteration for statement

30 messages
12
Open this post in threaded view
|

list iteration for statement

 ```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 ```
Open this post in threaded view
|

RE: list iteration for statement

 ```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/ --´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`-- ```
Open this post in threaded view
|

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 ```
Open this post in threaded view
|

Re: list iteration for statement

 ```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 ```
Open this post in threaded view
|

RE: list iteration for statement

 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 > ```
Open this post in threaded view
|

RE: list iteration for statement

 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/ --´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`-- ```
Open this post in threaded view
|

Re: list iteration for statement

 ```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 ```
Open this post in threaded view
|

Re: list iteration for statement

 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] ```
Open this post in threaded view
|

Re: list iteration for statement

 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. ```
Open this post in threaded view
|

Re: list iteration for statement

 ```>>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 ```
Open this post in threaded view
|

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. 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 ```
Open this post in threaded view
|

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 ```
Open this post in threaded view
|

RE: toLua 4.0a improvements

 ```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 ```
Open this post in threaded view
|

Re: toLua 4.0a improvements

 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 ```
Open this post in threaded view
|

Re: list iteration for statement

 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 ```
Open this post in threaded view
|

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

 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 ```
Open this post in threaded view
|

Lua on the podium again :-)

 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 ```
Open this post in threaded view
|

RE: Lua on the podium again :-)

 ```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). ```
Open this post in threaded view
|

Re: toLua 4.0a improvements

 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! ```
 ```> -----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