Re: __pairs metamethod - is it in?

["Ashwin Hirschi" <deery@...>]

> I think the real reason why 'for k,v in t' is deprecated is that it's
> both ambiguous and slow.

Supporting both tables and functions is ambiguous?

> At compile time it is not clear whether t is a table or a function.Therefore a (slow) runtime check in the form of an extra VMinstruction (OP_TFORPREP) is needed for _every_ iterator loop.

Since when is checking for "tableness" considered slow? Seriously, this kind of type-checking happens all the time.

Furthermore, the check is only needed (once!) at the beginning of the loop, right?

Last but not least, speed cost is relative and should be offset by the usual operation of Lua. Compared to many of the other mechanisms the cost of supporting tables in for-loops is peanuts.

Regarding the extra opcode: I believe it can be avoided. It looks like it's set up that way to make it (marginally) easier to chuck it out later... [?]

> And there's an implicit lookup of 'next' in the global table, too
> (which is ugly from a VM design standpoint).

Perhaps. I'm not that happy about the dependency on a global "next" either... Several alternative proposals have been floating around the list (in the past & recently) that I find more attractive.

For what it's worth: I'd like a mechanism where the table's able to provide a (meta-)function. That would enable a much more flexible (and controlled) operation.

Regardless, I believe it's up to the programmer to live with possible downsides of feeding tables into the for-loop construct. Once the mechanics are clear, people using tables knows the "price" they pay.

> The other argument is that most containers do not have just a single
> iterator. There are two standard iterators for plain tables and more could
> be conceived. And complex objects may provide dozens of iterators ...
> So which one do you expect to be used when you write 'for i in obj'?
> Which one do the readers of your code expect to be used?

The one that's already in place now. Simply iterate over everything. Clear & simple.

> Going with 'explicit is better than implicit', it's just good programming
> practice to spell out _which_ iterator you want to use. Remember that
> your code is much more often read than written. Therefore it is more
> important to convey your intentions clearly than to save a few keystrokes.

This point is well-made. And I'd agree with it in many, many situations.

Alas, it's also been used by many against garbage-collection... (and a truck-load of other very convenient things, many of which Lua provides wonderfully well).

In this particular case, I'd argue against always-being-explicit in favour of convenience:

Looking at the (Lua) code I've written over the last 2 or 3 years, I can honestly say that there are lots and lots (and lots) of table iterations (of the for-k-v-in-tab kind). None of them are slow. None of them are ambiguous in any way.

It's elegant & functional [pun intended?], so... why take all this away?

Ashwin.
--
no signature is a signature.