Any thoughts on indexing ...?

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

Any thoughts on indexing ...?

Alex Davies
Hey all,
 
Just wondered if the following syntax is being considered at all:
 
  for i = 1, #... do
    print(...[i])
  end
 
Imo it seems a natural extension, and less cumbersome then:
 
  local select = select
  for i = 1, select("#", ...) do
    print(select(i, ...))
  end
 
And would of course be orders of magnitude faster for large varargs.
 
It would also allow writing select in pure lua, something which is currently impossible.
Still, I can see that some people may not like the syntax, just wanted to throw it out
there anyway.
 
- Alex
 
P.S. I do realise it's a little inconsistent, as true lists will never be indexable... eg:
  local a = (1, 2, 3)[3]
Reply | Threaded
Open this post in threaded view
|

Re: Any thoughts on indexing ...?

Asko Kauppi

luaSub has a syntax mod exactly like your proposal (used by 'luas - sselect'):

--
-- SELECT syntax mod                   Copyright 2006-08 Asko Kauppi
--
-- Simplifies the 'select' usage a bit, making it look less like a function
--
--    #...    ->  select('#',...)   number of values in ...
--    ...[n]  ->  (select(n,...))   value #n of ...
--
-- Note: 'select(n,...)' is still used explicitly when wanting all values-- from 'n' onwards.
--


Alex Davies kirjoitti 9.4.2008 kello 9:38:
Hey all,

Just wondered if the following syntax is being considered at all:

 for i = 1, #... do
   print(...[i])
 end

Imo it seems a natural extension, and less cumbersome then:

 local select = select
 for i = 1, select("#", ...) do
   print(select(i, ...))
 end

And would of course be orders of magnitude faster for large varargs.

It would also allow writing select in pure lua, something which is currently impossible. Still, I can see that some people may not like the syntax, just wanted to throw it out
there anyway.

- Alex

P.S. I do realise it's a little inconsistent, as true lists will never be indexable... eg:
 local a = (1, 2, 3)[3]


Reply | Threaded
Open this post in threaded view
|

Re: Any thoughts on indexing ...?

eugeny gladkih
In reply to this post by Alex Davies
>>>>> "AD" == Alex Davies <[hidden email]> writes:

 AD>   local a = (1, 2, 3)[3]

it would be better to have

local a = {1, 2, 3}[3]   -- unexpected symbol near '[', why?

ps. there is weird solution: ({ 1,2,3 })[3]

-- 
Yours sincerely, Eugeny.
Doctor Web, Ltd. http://www.drweb.com
+79119997425

Reply | Threaded
Open this post in threaded view
|

Re: Any thoughts on indexing ...?

Luiz Henrique de Figueiredo
In reply to this post by Alex Davies
> Just wondered if the following syntax is being considered at all:
> 
>   for i = 1, #... do
>     print(...[i])
>   end

#...  already has a meaning, thought it's not what you want it to be: it
applies # to the first argument.

...[i] currently does not a meaning but if it did it would have to be the
same as (...)[i], which indexes the first argument.

Reply | Threaded
Open this post in threaded view
|

Re: Any thoughts on indexing ...?

Wesley Smith
>  ...[i] currently does not a meaning but if it did it would have to be the
>  same as (...)[i], which indexes the first argument.


How do the lua syntax rules lead to (...)[i] indexing the first
argument?  I don't follow the meaning of (...).

wes

Reply | Threaded
Open this post in threaded view
|

Re: Any thoughts on indexing ...?

Luiz Henrique de Figueiredo
> How do the lua syntax rules lead to (...)[i] indexing the first
> argument?  I don't follow the meaning of (...).

Any expression that results in a list of expressions, such as function call
or ..., can be enclosed in parenthese and the result is the first expression.

http://www.lua.org/manual/5.1/manual.html#2.5

Reply | Threaded
Open this post in threaded view
|

Re: Any thoughts on indexing ...?

Alexander Gladysh
In reply to this post by eugeny gladkih
> >>>>> "AD" == Alex Davies <[hidden email]> writes:
>
>   AD>   local a = (1, 2, 3)[3]
>
>  it would be better to have
>
>  local a = {1, 2, 3}[3]   -- unexpected symbol near '[', why?
>
>  ps. there is weird solution: ({ 1,2,3 })[3]

This is the feature of Lua syntax. You have to enclose table
constructor (or string literal for that matter) in braces deal with it
as with general variable.

Note that this solution has performance penalty as it allocates a new table.

Alexander.

Reply | Threaded
Open this post in threaded view
|

Re: Any thoughts on indexing ...?

Alex Davies
In reply to this post by Luiz Henrique de Figueiredo
----- Original Message ----- From: "Luiz Henrique de Figueiredo"

#...  already has a meaning, thought it's not what you want it to be: it
applies # to the first argument.
...[i] currently does not a meaning but if it did it would have to be the
same as (...)[i], which indexes the first argument.

Of course, apparently I didn't think that one through.

Back to trying to figure out at what point it's worth saving the varargs to a table over using the quadratic select, whilst keeping in mind that future versions of luajit are likely to completely optimise the select away ;).

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

Re: Any thoughts on indexing ...?

Mike Pall-84
Alex Davies wrote:
> And would of course be orders of magnitude faster for large varargs.

Well, yes. But large varargs are rare. Comparison here:

  http://lua-users.org/lists/lua-l/2006-04/msg00120.html

I still think apairs() would be a useful addition to Lua (5.2?).

It would be a concise replacement for the mess with select() over
varargs. It's a reappearing topic on the list, so I guess it has
now become a common idiom (I had to write such a loop for a test
case just yesterday).

And apairs() could replace the 'for i,x in pairs{a,b,c} do' idiom,
too. apairs() creates a closure, which is more lightweight than
creating a table plus its array part.

> Back to trying to figure out at what point it's worth saving the varargs to 
> a table over using the quadratic select,
> whilst keeping in mind that future versions of luajit are likely to 
> completely optimise the select away ;).

Yes, this is doable, but I'm not compiling calls to vararg
functions in LuaJIT 2.x (yet).

select(n, ...) with constant n can be reduced to some stack slot
shuffling and generates no code in an assignment-free SSA IR.

But a variant n would force a spill of '...' to the Lua stack
(which wouldn't be necessary if the number of args is known), ties
up a register for the Lua stack pointer, adds a bounds check and
type check and needs another register for the bound itself.

Interestingly this is more or less the same as a C compiler needs
to do to implement <stdarg.h>. TANSTAAFL.

--Mike

Reply | Threaded
Open this post in threaded view
|

Re: Any thoughts on indexing ...?

Mark Hamburg-4
on 4/9/08 5:47 AM, Mike Pall at [hidden email] wrote:

> And apairs() could replace the 'for i,x in pairs{a,b,c} do' idiom,
> too. apairs() creates a closure, which is more lightweight than
> creating a table plus its array part.

Though if we're worrying about optimization, it would be nice to recognize
that if given something like:

    for i, x in ipairs{ "a", "b", "c" } do
        --
    end

Then the constructed table can be lifted out as a constant.

Of course, that assumes that one knows what ipairs does and that it doesn't
modify the table in some way which of course we don't know...

Mark