Re: About a week with LUA_NOCVTN2S and LUA_NOCVTS2N

["Thierry@spoludo" <thierry@...>]

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)

You may also decide to  avoid an order in the generation 
ie, instead of  {1,1,1,1},{1,1,1,2},{1,1,1,3},...
Have different de coupled policies to first test the limits  {1,1,1,1},{5,5,5,5},‎..
Or ‎ pure random generation of the vectors
{4,2,1,5},{2,3,3,4},... 
‎
‎You don't need to make the iterator that complex at first, but with creating an abstraction at this level you get more potential. 
‎

‎
‎
‎