'for' syntax (was Re: Lua 5.1 (work6) now available (for loop))

[Mike Pall <mikelu-0505@...>]

Hi,

Asko Kauppi wrote:
> Joshua Jensen kirjoitti 19.5.2005 kello 10.09:
> >Can anyone point me to the discussion and rationale for this?  I've  
> >just
> >spent the past while searching the mailing list archives.  I must be
> >searching for the wrong keywords.
> 
> http://archive.neotonic.com/archive/lua-l/browse_frm/thread/3114/26239
> seems to be broken, so I'll put a copy here:
> 
> (note that this is just one message, and the "slow" was causing  
> discussion.
> but it should lead you to the right thread anyhow..)  If there's a  
> '__pairs'
> metamethod, you'd be able to revert to the old behaviour for tables, but
> selectively choose the best (default) iterator for them.

Umm well, since you are quoting me ... just to set this straight:
yes, the 'slow' is mostly irrelevant. The 'ambiguous' is not.

But please note that I just tried to give a rationale (because I
couldn't find one in the archives, too). The Lua authors made this
decision long ago. Have a look at the end of the Lua 5.0 manual
(anno 2003) where it lists the incompatibilities with 4.0:

| The old construction for k,v in t, where t is a table, is deprecated
| (although it is still supported). Use for k,v in pairs(t) instead.

So maybe I should rephrase my statement:

The 'for i in table' syntax predates the iterator syntax (4.0).
Maybe the historic accident was to give 'for i in expr' two
different syntactic meanings (5.0). Probably with the intention
to provide a smoother migration path. Alas, now that the migration
to the new syntax is complete (5.1), it seems many people got
more accustomed to the syntactic duality than to the new syntax.

On a more practical level: there's no way out of the dilemma
right now. Introducing yet another syntax (e.g. 'for i over obj')
won't help. This may be a step backwards and only prolong
the migration path.

>From the viewpoint of a language designer, the choice the Lua
authors made is crystal clear: unambiguity beats convenience
(and right so, IMHO).

And to repeat something from the other thread: the issue of
a 'canonical iterator' (i.e. a __pairs or __iter metamethod)
is completely orthogonal to the syntactic problem.

IMHO either pairs() (and maybe ipairs() or maybe not) or even
a new iter() function (a better name for the canonical case) could
do the check for the (non-core) metamethod(s). With a little bit
of help on the C API side this could be made quite fast. This
would also benefit tostring() and it may encourage wider use of
user-defined metamethods, too.

Bye,
     Mike