Re: '__iter', yet again!

[Mark Hamburg <mark@...>]

On Dec 16, 2009, at 7:32 AM, Mark Hamburg wrote:

> There's an interesting general argument (meta-argument) there about the notion that the Lua language has a certain number of syntactic/semantic constructs and of those a subset can be overridden via metamethods. The structure of that subset is guided by concerns over issues such as speed, size, and semantics but growing that subset is not a fundamental change in the language though it may introduce new capabilities.
> 
> Besides iteration, some other metamethod extensions that come up include:
> 
> * First class treatment in some form for the colon operator -- i.e., allow it to be more than just syntactic sugar
> * Altered semantics for __index to handle recursive usage -- e.g., pass the base table along
> * Altered semantics for __newindex and/or a new metamethod to catch all writes without needing to use a proxy table
> 
> In this case, the proposal is for the inclusion of an extra step that would execute after evaluating the expression list for a for loop but before actually invoking the loop. The primary cost there would seem to be speed -- it affects all iterations though only slightly if the iteration is large -- and of course VM size. A program that made heavy use of the construct could potentially earn back the VM size cost fairly rapidly.
> 
> The proposed semantics, if I gather correctly, are "if the value of the first expression is not a function (fast exit path) and it has an __iter metamethod then invoke that metamethod to get the iterator". What happens, however, if there are multiple expressions in the list? Does the rule just not apply? Does the __iter metamethod receive the additional values as parameters?

The above applies with or without objects though its primary motivation is clearly object-oriented. That said, there is also a big chunk of the motivation that comes from wanting to work in a purely functional context with iterator factories and not have to remember at the end to do the type conversion to an iterator.

That said, the proposed extension also applies if you take "metamethods are about exceptional conditions not about overriding semantics" stance. In this case, the exceptional condition is that the iterator function isn't a function and will fail when we call it. The __iter metamethod provides an opportunity to handle that exception. The boundary gets fuzzier if the iterator function is an object with a __call metamethod, but one could argue that that is essentially just another fallback case.

Mark