Re: list iteration for statement

[Edgar Toernig <froese@...>]

John Belmonte wrote:
> 
> I realized that a subtle issue about making this change to Lua is that it
> requires the vm to know about lists.

The vm already knows about lists.  It builds them for var arg functions...

> (It looks like in Sol, Edgar gets around this by using different semantics,
> where a list ends at the first nil element.  This drags out the nil as false
> issue again.)

I prefer this definition of a list.  It will never traverse more elements
than are really present in the table.  I'm thinking about redefining getn
too.  Try processing { [1e33]=1 } ...

> If it is acceptable for the vm to know about lists, it may be worth
> considering some efficiency improvements at the same time.  It seems tricky
> to implement well, but the existence and correctness of the "n" field could
> be an invariant managed by the vm.

Indeed very tricky when implemented with regular tables.  The question is,
is it really necessary?  With my semantic of the list loop [1] an 'n'
field (or getn function) is not required.  And the other "most common use
of n/getn" would be (I guess) tappend.  And for that there may be simpler
optimizations.

Ciao, ET.


[1] We have different syntax.  You decide on the number of vars whether
it's a table-for or a list-for:

table:   for <var>,<var> in <table> do ... end
list:    for <var> in <list> do ... end

I've chosen the reserved word `over' for the list-for and made one var
optional in both versions:  (btw, `in' is reserved now too)

table:   for <var>[,<var>] in <table> do ... end
list:    for [<var>,]<var> over <list> do ... end


But I'm not sure if this is really the right way to go.  A much more
elegant (but slower) variant would be to have a `next' tag method.
Then you could use the regular for-in-loop for everything.  I.e.:

function List(t)  settag(t, list_tag_with_special_next) return t  end

for i,v in List { "a", "b", "c" } do ... end