I miss table.foreach

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

I miss table.foreach

Roland
Since Lua 5.1, table.foreach and table.foreach were deprecated[1].
It is known (I am such a fan of Game Of Thrones... :)).

I would just like to know why. Are there good reasons to this ?
I bet there are, as looking at the evolution of Lua, nothing is seems
to be done without some solid motives at the basis.

But to me, this syntax was so much beautiful:

    table.foreach({...}, print)

It misses me under Lua 5.2.x.
Well, I am not saying I want it back. Just looking for...reasons.
Thanks reading.

Regards,
Roland Y.

[1] http://www.lua.org/manual/5.1/manual.html#7.2

Reply | Threaded
Open this post in threaded view
|

Re: I miss table.foreach

Hisham
On 4 September 2013 19:25, Ousmane Roland Yonaba
<[hidden email]> wrote:

> Since Lua 5.1, table.foreach and table.foreach were deprecated[1].
> It is known (I am such a fan of Game Of Thrones... :)).
>
> I would just like to know why. Are there good reasons to this ?
> I bet there are, as looking at the evolution of Lua, nothing is seems
> to be done without some solid motives at the basis.
>
> But to me, this syntax was so much beautiful:
>
>     table.foreach({...}, print)
>
> It misses me under Lua 5.2.x.
> Well, I am not saying I want it back. Just looking for...reasons.

This foreach function was present in Lua before the actual "for"
command was included, which amazingly was rather late in the
language's history (Lua 4.0 in 2000).

When they added "for", table.foreach became somewhat redundant,
because we had "for k,v in t", which produced similar funcionality.
Then that was removed too, replaced by the generator functions, so now
we have "for k,v in pairs(t)" and "for i,v in ipairs(t)". Then for a
while during work versions of Lua 5.2 the Lua authors even considered
getting rid of ipairs and making us use "for i=1,#t do" but
fortunately they retracted that change.

I for one miss "for k,v in t", as it is by far the most common
iteration pattern and IMHO deserved that special case (and there are
other places in the language where behavior changes if the value is a
function or a table anyway, such as __index in metatables and the repl
argument in string.gsub).

I'm not _saying_ I want it back, I appreciate the efforts for
orthogonality and minimalism... but I miss it. :)

-- Hisham
http://hisham.hm/

Reply | Threaded
Open this post in threaded view
|

Re: I miss table.foreach

Tim Hill
In reply to this post by Roland

On Sep 4, 2013, at 3:25 PM, Ousmane Roland Yonaba <[hidden email]> wrote:

> Since Lua 5.1, table.foreach and table.foreach were deprecated[1].
> It is known (I am such a fan of Game Of Thrones... :)).
>
> I would just like to know why. Are there good reasons to this ?
> I bet there are, as looking at the evolution of Lua, nothing is seems
> to be done without some solid motives at the basis.
>
> But to me, this syntax was so much beautiful:
>
>    table.foreach({...}, print)
>
> It misses me under Lua 5.2.x.
> Well, I am not saying I want it back. Just looking for...reasons.
> Thanks reading.
>
> Regards,
> Roland Y.
>
> [1] http://www.lua.org/manual/5.1/manual.html#7.2
>

It's pretty easy to add it back in with a few lines of Lua code…

-- NOT TESTED
function tableForEach(t, f)
        for _, v in pairs(t) do f(v) end
end

There are endless variations of course.

--Tim


Reply | Threaded
Open this post in threaded view
|

Re: I miss table.foreach

slayer beast
if not table.foreach then
  table.foreach = function(t, f)
    for k, v in pairs(t) do f(k, v) end
  end
end


On Wed, Sep 4, 2013 at 7:36 PM, Tim Hill <[hidden email]> wrote:

On Sep 4, 2013, at 3:25 PM, Ousmane Roland Yonaba <[hidden email]> wrote:

> Since Lua 5.1, table.foreach and table.foreach were deprecated[1].
> It is known (I am such a fan of Game Of Thrones... :)).
>
> I would just like to know why. Are there good reasons to this ?
> I bet there are, as looking at the evolution of Lua, nothing is seems
> to be done without some solid motives at the basis.
>
> But to me, this syntax was so much beautiful:
>
>    table.foreach({...}, print)
>
> It misses me under Lua 5.2.x.
> Well, I am not saying I want it back. Just looking for...reasons.
> Thanks reading.
>
> Regards,
> Roland Y.
>
> [1] http://www.lua.org/manual/5.1/manual.html#7.2
>

It's pretty easy to add it back in with a few lines of Lua code…

-- NOT TESTED
function tableForEach(t, f)
        for _, v in pairs(t) do f(v) end
end

There are endless variations of course.

--Tim



Reply | Threaded
Open this post in threaded view
|

Re: I miss table.foreach

Andrew Starks
In reply to this post by Hisham


On Wednesday, September 4, 2013, Hisham wrote:

I for one miss "for k,v in t", as it is by far the most common
iteration pattern and IMHO deserved that special case (and there are
other places in the language where behavior changes if the value is a
function or a table anyway, such as __index in metatables and the repl
argument in string.gsub).

I'm not _saying_ I want it back, I appreciate the efforts for
orthogonality and minimalism... but I miss it. :)

-- Hisham
http://hisham.hm/

One would not like to be caught redesigning Lua on this list! :)

if i did, then I'd say that it would be nice if "for" received a table after "in", it would look for the "__in" metamethod and call it with the table as the argument. 

It isn't a big deal though, wich is why I won't wish for it publicly

:)

-Andrew
Reply | Threaded
Open this post in threaded view
|

Re: I miss table.foreach

Tiago Salmito
In reply to this post by slayer beast
On Wed, Sep 4, 2013 at 8:44 PM, slayer beast <[hidden email]> wrote:
if not table.foreach then
  table.foreach = function(t, f)
    for k, v in pairs(t) do f(k, v) end
  end
end


On Wed, Sep 4, 2013 at 7:36 PM, Tim Hill <[hidden email]> wrote:

On Sep 4, 2013, at 3:25 PM, Ousmane Roland Yonaba <[hidden email]> wrote:

> Since Lua 5.1, table.foreach and table.foreach were deprecated[1].
> It is known (I am such a fan of Game Of Thrones... :)).
>
> I would just like to know why. Are there good reasons to this ?
> I bet there are, as looking at the evolution of Lua, nothing is seems
> to be done without some solid motives at the basis.
>
> But to me, this syntax was so much beautiful:
>
>    table.foreach({...}, print)
>
> It misses me under Lua 5.2.x.
> Well, I am not saying I want it back. Just looking for...reasons.
> Thanks reading.
>
> Regards,
> Roland Y.
>
> [1] http://www.lua.org/manual/5.1/manual.html#7.2
>

It's pretty easy to add it back in with a few lines of Lua code…

-- NOT TESTED
function tableForEach(t, f)
        for _, v in pairs(t) do f(v) end
end

There are endless variations of course.

--Tim




If the function f returns a non-nil value the iteration loop terminates. [1]

 if not table.foreach then
  table.foreach = function(t, f)
    for k, v in pairs(t) do if f(k, v)~=nil then break end end
  end
end


Reply | Threaded
Open this post in threaded view
|

Re: I miss table.foreach

Tim Hill
In reply to this post by Andrew Starks

On Sep 4, 2013, at 5:31 PM, Andrew Starks <[hidden email]> wrote:

> One would not like to be caught redesigning Lua on this list! :)
>
> if i did, then I'd say that it would be nice if "for" received a table after "in", it would look for the "__in" metamethod and call it with the table as the argument.
>
> It isn't a big deal though, wich is why I won't wish for it publicly
>
> :)
>
> -Andrew

Another example of the somewhat incomplete use of metamethods in Lua at present. However, remember that for "for … in ..." statement really expects three arguments, not one (we are just used to all three being the return values of a generator function such as pairs()). Not saying it can't be done, though.

--Tim


Reply | Threaded
Open this post in threaded view
|

Re: I miss table.foreach

Andrew Starks


On Wednesday, September 4, 2013, Tim Hill wrote:

On Sep 4, 2013, at 5:31 PM, Andrew Starks <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;andrew.starks@trms.com&#39;)">andrew.starks@...> wrote:

> One would not like to be caught redesigning Lua on this list! :)
>
> if i did, then I'd say that it would be nice if "for" received a table after "in", it would look for the "__in" metamethod and call it with the table as the argument.
>
> It isn't a big deal though, wich is why I won't wish for it publicly
>
> :)
>
> -Andrew

Another example of the somewhat incomplete use of metamethods in Lua at present. However, remember that for "for … in ..." statement really expects three arguments, not one (we are just used to all three being the return values of a generator function such as pairs()). Not saying it can't be done, though.

--Tim


True. Also, my non-existent idea was kinda dumb in that "__next" is really the last missing iterator metamethod, not "__in". 
Reply | Threaded
Open this post in threaded view
|

Re: I miss table.foreach

Dirk Laurie-2
2013/9/5 Andrew Starks <[hidden email]>:
>> On Sep 4, 2013, at 5:31 PM, Andrew Starks <[hidden email]> wrote:
>>
>> > One would not like to be caught redesigning Lua on this list! :)

Oh? It is being done quite often. People who point out that some
suggested extension is actually quite easy to achieve with
currently available features, tend to be tagged as language lawyers.

> Also, my non-existent idea was kinda dumb in that "__next"
> is really the last missing iterator metamethod, not "__in".

Call it "__in", "__next", "__iter", nothing dumb in a name, it's
the idea that counts.

The difficulty is that "in" expects a callable. Anything with a "__call"
metamethod is a valid target for "in".

Unfortunately "__call" works too hard. Some object-oriented styles
use "__call" as a constructor, but then it is not available as an iterator.

So maybe "in" should not expect a callable, it should expect an iterable,
which is anything with an "__iter" metamethod (or "__in", or "__next",
what you will.).

In that case, the question arises what should be done if someone
uses debug.setmetatable to set an "__iter" metamethod for functions.
Should it still be ignored as in the case of "__call" since Lua knows
what to do, or should it now override the calling of the function?

Reply | Threaded
Open this post in threaded view
|

Re: I miss table.foreach

David Demelier
In reply to this post by Roland
2013/9/5 Ousmane Roland Yonaba <[hidden email]>:

> Since Lua 5.1, table.foreach and table.foreach were deprecated[1].
> It is known (I am such a fan of Game Of Thrones... :)).
>
> I would just like to know why. Are there good reasons to this ?
> I bet there are, as looking at the evolution of Lua, nothing is seems
> to be done without some solid motives at the basis.
>
> But to me, this syntax was so much beautiful:
>
>     table.foreach({...}, print)
>
> It misses me under Lua 5.2.x.
> Well, I am not saying I want it back. Just looking for...reasons.
> Thanks reading.
>
> Regards,
> Roland Y.
>
> [1] http://www.lua.org/manual/5.1/manual.html#7.2
>

For me, I personally miss more something like table.find (which never
existed). A kind of function like that would be great :-), there's
also table.sort so table.find could be a great improvement.

Cheers,

--
Demelier David

Reply | Threaded
Open this post in threaded view
|

Re: I miss table.foreach

Tim Hill
In reply to this post by Dirk Laurie-2

On Sep 4, 2013, at 11:34 PM, Dirk Laurie <[hidden email]> wrote:

The difficulty is that "in" expects a callable. Anything with a "__call"
metamethod is a valid target for "in".

Really? I was under the impression it wanted an expression list (of which it uses only the first three items). In which case I don't see the ambiguity between __call and __in (or whatever it could be called).

--Tim

Reply | Threaded
Open this post in threaded view
|

Re: I miss table.foreach

steve donovan
In reply to this post by David Demelier
On Thu, Sep 5, 2013 at 8:52 AM, David Demelier <[hidden email]> wrote:
> For me, I personally miss more something like table.find (which never
> existed). A kind of function like that would be great :-),

The point is that table.find in C would probably not be _much_ faster
than the Lua version, although it would be interesting to have some
data.

This is why we have libraries, even if they're not standard ;)

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: I miss table.foreach

Dirk Laurie-2
In reply to this post by Tim Hill
2013/9/5 Tim Hill <[hidden email]>:
>
> The difficulty is that "in" expects a callable. Anything with a "__call"
> metamethod is a valid target for "in".
>
>
> Really? I was under the impression it wanted an expression list
> (of which it uses only the first three items). In which case I don't
> see the ambiguity between __call and __in (or whatever it could
> be called).

At the syntax level (dare I call it the language lawyer level?)
you are right, of course. But what Lua does to the first of those
expressions is to try to call it.

$ lua
Lua 5.2.2  Copyright (C) 1994-2013 Lua.org, PUC-Rio
> for k in 3 do print(k) end
stdin:1: attempt to call a number value

Reply | Threaded
Open this post in threaded view
|

Re: I miss table.foreach

steve donovan
On Thu, Sep 5, 2013 at 9:06 AM, Dirk Laurie <[hidden email]> wrote:
> you are right, of course. But what Lua does to the first of those
> expressions is to try to call it.

And that's indeed the problem; if an object has __call defined, then
it will use that.  If __iter is defined, that would be tried first.

So we would get a clear notation for objects which are 'list-like' and
define __iter as a iterator constructor.

for x in obj do: print(x) end

Python envy?  We should be not too afraid of what Python does; I think.

This is something that would give 5.3 a definite increase in expressiveness...

Reply | Threaded
Open this post in threaded view
|

Re: I miss table.foreach

Tim Hill
In reply to this post by Dirk Laurie-2

On Sep 5, 2013, at 12:06 AM, Dirk Laurie <[hidden email]> wrote:

Really? I was under the impression it wanted an expression list
(of which it uses only the first three items). In which case I don't
see the ambiguity between __call and __in (or whatever it could
be called).

At the syntax level (dare I call it the language lawyer level?)
you are right, of course. But what Lua does to the first of those
expressions is to try to call it.

$ lua
Lua 5.2.2  Copyright (C) 1994-2013 Lua.org, PUC-Rio
for k in 3 do print(k) end
stdin:1: attempt to call a number value

Urgh .. what a mess. That's certainly not what the Lua Ref manual says, and is not consistent with other places that expression lists are used.

--Tim

Reply | Threaded
Open this post in threaded view
|

Re: I miss table.foreach

Choonster TheMage
On 5 September 2013 17:25, Tim Hill <[hidden email]> wrote:

>
> On Sep 5, 2013, at 12:06 AM, Dirk Laurie <[hidden email]> wrote:
>
> Really? I was under the impression it wanted an expression list
> (of which it uses only the first three items). In which case I don't
> see the ambiguity between __call and __in (or whatever it could
> be called).
>
>
> At the syntax level (dare I call it the language lawyer level?)
> you are right, of course. But what Lua does to the first of those
> expressions is to try to call it.
>
> $ lua
> Lua 5.2.2  Copyright (C) 1994-2013 Lua.org, PUC-Rio
>
> for k in 3 do print(k) end
>
> stdin:1: attempt to call a number value
>
>
> Urgh .. what a mess. That's certainly not what the Lua Ref manual says, and
> is not consistent with other places that expression lists are used.
>
> --Tim
>

The manual says that the results of the expression list "...are an
iterator function, a state, and an initial value for the first
iterator variable."[1][2] The "equivalent" code shows `f` (an iterator
function, the first value from the expression list) being called with
`s` and `var` (the state and the first iterator variable, the second
and third values from the expression list) as arguments to produce the
new values for the loop variables.

[1] http://www.lua.org/manual/5.1/manual.html#2.4.5
[2] http://www.lua.org/manual/5.2/manual.html#3.3.5

Reply | Threaded
Open this post in threaded view
|

Re: I miss table.foreach

Dirk Laurie-2
2013/9/5 Choonster TheMage <[hidden email]>:

> The manual says that the results of the expression list "...are an
> iterator function, a state, and an initial value for the first
> iterator variable."

The use of the term "iterator function" rather than just "function"
gives us Lua redesigners some room to manoeuvre in. The two
concepts have already been separated; it becomes just an
argument about semantics.

Reply | Threaded
Open this post in threaded view
|

Re: I miss table.foreach

Jorge Visca
In reply to this post by Dirk Laurie-2
I'll say this: I don't like intensive use of metamethods. It's
/perhaps/ ok for really basic __index and __newindex stuff... But
anything else confuses me when reading code. I dont't know why, but
suspecting there might be some crazy side-effects makes me anxious.



Reply | Threaded
Open this post in threaded view
|

Re: I miss table.foreach

steve donovan
On Thu, Sep 5, 2013 at 4:23 PM, Jorge <[hidden email]> wrote:
> I'll say this: I don't like intensive use of metamethods. It's /perhaps/ ok
> for really basic __index and __newindex stuff... But anything else confuses
> me when reading code. I dont't know why, but suspecting there might be some
> crazy side-effects makes me anxious.

Well yes, it does raise the 'magic' level of the code.  I stopped
liking C++ when I realized that _anything_ could happen at any line.
Life in Lua is better when we can clearly read the intent, so
metamethods can be abused like operator overloading.  'for k,v in
pairs(t) .. ' has no magic, 'for v in t' has got magic.  Is the price
of the magic worth the extra few less keystrokes?  That's a question I
don't have an answer for - it depends whether I'm a writer or a reader
;)

Reply | Threaded
Open this post in threaded view
|

Re: I miss table.foreach

Steve Litt
In reply to this post by David Demelier
On Thu, 5 Sep 2013 08:52:47 +0200
David Demelier <[hidden email]> wrote:


> For me, I personally miss more something like table.find (which never
> existed). A kind of function like that would be great :-), there's
> also table.sort so table.find could be a great improvement.
>
> Cheers,

You could easily write your own table.find that iterates through all
items til it finds a value that matches the argument. But it would be
slow with big tables.

More practical might be to have an index table whose keys are the value
or value part in question, and whose values are the key of the original
table. Then you write your table.find something like

orgtable[indextable["searchkey"]]

You'd probably put an add metamethod on orgtable to write the correct
entry to indextable.

I'm not a Comp Sci expert, but I'd imagine this would continue to have
fast lookups, on a one by one basis, even if you had 10K items in the
lists.

Thanks,

SteveT

Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance

12