Re: About a week with LUA_NOCVTN2S and LUA_NOCVTS2N

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

‎It was thus said that the Great Sean Conner once stated:‎ 
(so that at least it fairly happens once to you...)


> ‎I'm in the process of enumerating test 

Why calling it list and not enum, then? 

  ‎> In my
opinion, trying to reduce the number of keystrokes when writing code
often *adds* to the cognitive load of knowing that the code is doing
and it becomes more dense and hard to follow.

And isn't the problem rather not enough abstraction in your example? (getting closer to math density!!!)

What is the right level of abstraction? I took a look at the first article to mention and it seems to point to rather too much abstraction issue‎. In its time policy based design was trying to find the right levels of abstractions.

‎I think this is really related to the signifier significant duality (back to Ferdinand de Saussure‎), that also explains why programing language are organized by communities defensive on their idioms and coding culture. Maybe semiotics has tools that could help improving programing languages.  

But I've hijacked too much the thread and landed on territories where i'm almost ignorant. Yet, back to your example with‎ less typing and more abstraction:

Bools={ false, true}
Signature=‎{
 Bools,
 ‎{ 'variation-a' , 'variation-b' , 'variation-c' },
...
}
for vparms in vecenum(signature, [ acceptallvec, 'ordered' ]) do
  ‎ A, B, C, D = unpack(vparms) -- can be done in vecenum... but better semantic if returning a vector.

More signified?