Abstractions in Lua (was Re: About a week with LUA_NOCVTN2S and LUA_NOCVTS2N)

[Sean Conner <sean@...>]

It was thus said that the Great Thierry@spoludo once stated:
> I'm enumerating all the possible combinations. For example:
> 
> for a in 1,5 do
> for b in 1,5 do
> for c in 1,5 do
> for d in 1,5 do
> print(a,b,c,d)
> end
> end
> end
> end
> 
> I'm failing to see how your code does that.
> --
> 
> Well, it's true an abstraction needs being documented as the name itself
> might not be enough (but naming patterns can create a culture) . This is
> maybe why open-source is winning with white boxing, and why I love text
> editor that can show specs when staying on a name.
> 
> What I was intending to say, is that if you feel that you need raising the
> abstraction and at the same time feel that you didn't raise it much, you
> may actually have missed an opportunity to raise it at a more beneficial
> level. 
> 
> Benefits can be shorter code, reuse (enforcing the culture), sub logic
> decoupling (pipelining), vectorization can ease parallelism. Maybe having
> such a mental list when abstracting can help thinking of all the benefits
> one may reach when we are chasing one of them.
> 
> In the code, each for loop is iterating an enum. If you consider all the
> loops at once, you are actually iterating a vector {a, b, c, d} . So you
> can rise the abstraction to iterating a finite set of enumeration (and
> lower cyclomatic number). 
> 
> You then gain that the vector can have any size. And with defining an
> iterator, you may optionally filter out some invalid vectors (instead of
> adding if within the inner loop logic)

  Ah, I see what you were getting at now.  So, instead of the nested for
loops, you do something like:

data =
{
  A = { false , true } ,
  B = { 'tel' , 'sip' } ,
  C = { 'tel' , 'sip' } ,
  D = { false , true } ,
  E = { 'opt1' , 'opt2' , 'opt3' } ,
}

permutate(data,callback,'ordered','all')

where permutate() does the actual work, possibly doing it in parallel or
whatever nastiness it pertains.  Fair enough, but you have to keep in mind
how often such an abstraction is used before spending time making the
abstraction in the first place.  In our case, this is the second time (in
four years) this issue has come up, and the first time we just brute forced
it by enumerating all the cases in a spreadsheet (and then, it was someone
else that did the enumerating).  

  This time, there are way more variables to iterate through and this is
straightforward enough (and rare enough) that doing simple for loops is good
enough (especially since they're paying me to develop a feature for
telephones, not writing elegant abstractions to generate permutations).

  But even the above is still trying to shoehorn an abstrction into Lua.  If
I were to get all abstracty on the issue, I might do something like:

data = [[
: ordered

A boolean
B [ tel sip ]
C [ tel sip ]
D boolean
E [ 
	{ opt1 :      A = false D = N/A }
	{ opt2 opt3 : A = true  D = false } 
	{ opt4 :      A = true  D = true }
  ]
]]

And have some LPeg expression parse and generate code, but I would only do
this if I (personally, or at work) needed to generate whole masses of
permutated data according to some bizarre set of rules (and I would try to
get as many examples of conditions to work out a consise language to express
everything needed).

  -spc (But now I've introduced a new language into the mix ... )