Re: Why do we have ipairs?

[William Ahern <william@...>]

On Thu, Jun 26, 2014 at 05:39:51PM -0400, Sean Conner wrote:
> It was thus said that the Great William Ahern once stated:
> > 
> > What about label references? That is, if Lua allowed directly taking a
> > reference to a label? Then you could use them directly, as when writing a
> > classic state machine, or build your own jump tables which mapped keys to
> > labels. Although you might have to add an optimization to memoize constant
> > tables in the latter case.
> > 
> > The label reference would have to be a new native type. But it might be a
> > little more elegant at the syntax level.
> > 
> > State machine example
> 
>   For state machines, you can use functions, because Lua supports tail call
> optimizations, which are essentially gotos.  I implemented TFTP using that
> method:

The problem with using functions in that manner is locality of context. It's
why people prefer using switch statements in C rather than tables of
function pointers. Why people scoff at Microsoft telling people to use
function pointer tables as an excuse for not adding computed gotos to Visual
Studio, and why callbacks suck compared to coroutines.

It's soooo much easier to analyze and comprehend the flow of control in a
simple series of adjoining statements than it is across a series of function
calls, especially recursive calls. While the fundamental logic is similar,
the working set of moving parts is much less, and our brains have a very
limited and astonishingly universal (i.e. IQ doesn't help much) capacity for
working set memory. So, for example, with a concise state machine you don't
need to reproduce as much epilogue and prologue boilerplate code (i.e. entry
and exit disciplines), which makes it easier to write and edit. And visually
you can simply pack more in, so it's physically quicker to wade through the
logic. With a complex state machine (it doesn't make sense to write a simple
one), there's no substitute for grasping the machine as a whole, and in IMO
comments, florid code, and indirection just compound the difficulties.

There are situations when the opposite is true, but those are exceptional,
IMO.

Note that I don't necessarily agree that Lua needs a switch statement or
computed gotos. Where I might use state machines in C I usually use
coroutines in Lua, presuming I couldn't get away with a simple iterator.
Although obviously that requires rethinking the whole approach at a much
higher level. And I'm not shy about switching between Lua and C, and using
whichever language makes the most sense. Obviously writing Lua code is
faster and easier for myself and others to hack on, but if doing so makes
the solution akward or I feel like it would just be more straight forward in
C, I have no compunction switching to C.

Others have different personal preferences or imposed restrictions, though.
So I'm not necessarily averse to these suggestions, either.