Re: Numeric for loops...

[Eike Decker <zet23t@...>]

2010/5/29 Jonathan Castello <twisolar@gmail.com>:
> On Sat, May 29, 2010 at 12:21 AM, duck <duck@roaming.ath.cx> wrote:
>>
>> The numeric 'for' loop is so simple, so quick, so easy to explain, so
>> commonplace in programming (and so commonly provided in programming
>> languages), and so jolly useful that I would like to suggest that we all
>> agree to stop calling for its removal :-)
>>
>> Lua has comparatively little redundancy compared to other languages. The
>> sheer convenience and compactness of being able to write the short and
>> sweet:
>>
>>  for i = 1,#list do
>>     ...
>>  end
>>
>> surely justifies keeping the construct for ever?
>>
>
> I think it's slightly lamentable that "for i=1, 10, 100" is almost
> identical to "for i in 1, 10, 100", but that's just me. I definitely
> think ipairs() should stay in some form.

I don't think ipairs is of any importance. It's easy to emulate and
its removal show that the Lua developers are interested in keeping Lua
as small as possible - I wouldn't have dared to think about removing
ipairs, but after evaluating their decission, I came to the conclusion
that they are right and that it's justified to get rid of that
function. Actually, I hardly used ipairs anymore myself.

The beauty of the i=start,end,increment semantic is, that it's known
to a very fast loop that, once started, does not evaluate any
conditions anymore. When manipulating an image (or a similar 2D
structure) and doing some kernel operation (which I do often), I
usually write something like this:

  for x=-kwidth,kwidth do
    for y=-kheight,kheight do
    end
  end

and I know that it's the fastest way how to do it and it's easy to
read. You might still argue that something like

  for x,y in area(-kwidth,-kheight,kwidth,kheight) do end end

might be more convenient, but as you see, it's not really much of a
difference to write - actually, it's just as long as the "unrolled"
variant if you exclude indenting. On top of it, it's less performant
and the reader must be aware of its meaning, which is sometimes hard
to track in a dynamic environment. And when doing things like that,
performance of these inner loops is really important and it makes a
huge difference.

I am happy with the fact that the Lua development does not follow the
trend of "bigger is better" and that it remains small and fast (and
cute :)). Even if sometimes a function is dropped that I liked so much
(like setfenv).

Cheers,
Eike