Re: Abolishing the numeric-for

[Jonathan Castello <twisolar@...>]

On Mon, May 24, 2010 at 3:33 PM, M Joonas Pihlaja
<jpihlaja@cc.helsinki.fi> wrote:
> Rereading the proposal I'm no longer sure how it's supposed to work
> exactly.  Any chance of presenting it in pseudocode at the level of
> http://www.lua.org/manual/5.1/manual.html#2.4.5 "A for statement ...
> is equivalent to the code ..." ?
>

I found my error, hopefully this will clear it up. My example before
of "pairs(t)" being equivalent to "pairs, t" was based off of a faulty
mental model, and it shouldn't work.

----
do
  local object = table.remove(params, 1)

  local obj_meta = getmetatable(object)
  if type(object) == "number" and
      not (obj_meta or obj_meta.__iter) then
    local var   = tonumber(object)
    local limit = tonumber(params[1])
    local step  = tonumber(params[2])

    -- use numeric for
  else
    local f, s, var
    if obj_meta.__iter then
      f, s, var = obj_meta.__iter(obj, params)
    elseif type(object) == "table" then
      f, s, var = pairs(obj, params)
    end

    -- use generic for
  end
end
----

> Regarding speed of numeric for and setup overhead of your "for i in
> 100,1,1 do" style loop, you asked if the compiler couldn't optimise
> the latter into the equivalent of a numeric for.  The answer to that
> is probably "no, it can't (without significant effort)" because the
> user can change the metatable of numbers whenever they please to make
> the loop go up, down or sideways.

Yes; that's why I qualified it before as "a number without an __iter".
I wouldn't expect the VM to handle cases like that, but I doubt
there's a good reason to change __iter on a number anyways, so you're
not going to have many cases where the VM can't optimize a numeric
iteration.


Hope the code helps!
~Jonathan