Re: Why do we have ipairs?

[Sean Conner <sean@...>]

It was thus said that the Great William Ahern once stated:
> 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. 

  True, but we're not talking about C, we're talking about Lua.

> 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.

  Computed gotos, in the context of C, is a compiler extension and not part
of the C language.

> 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. 

  I'll grant you it can feel wierd at first, seeing a bunch of functions all
call each other and not blow out the stack, but with exposure, you get used
to it.  Heck, people got used to Perl, for crying out loud.

> 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. 

  Here I'm not following you.  In Lua, you can make the state local to all
the functions making up the state machine, or pass it around in a table. 
Even in C, I don't think the overhead is as much as you are making it out to
be, unless you *reallly* hate typing "return".

> 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.

  I've only done state machines for two purposes---parsing, and protocol
handling.  And frankly, if I'm in Lua, I'll leave the parsing to LPeg.  That
just leaves handling protocols, and there, I found using mutually recursive
functions is much easier to deal with than just about anything else.

> 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.

  I think you are conflating state machines with coroutines.  I don't see
how a coroutine (or two) can be used to implement state machines.

  -spc (I've used coroutines to handle network services, but for those, the
	protocol is a more straightforward request, wait for response type
	of thing)