[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: About a week with LUA_NOCVTN2S and LUA_NOCVTS2N
- From: Sean Conner <sean@...>
- Date: Sat, 24 Jan 2015 03:13:54 -0500
It was thus said that the Great Thierry@spoludo once stated:
> > It was thus said that the Great Sean Conner once stated:
> (so that at least it fairly happens once to you...)
Thank you.
> > I'm in the process of enumerating test
>
> Why calling it list and not enum, then?
I thought that just after I wrote the message. I think at the time I was
writing the code, I was thinking of C's enum (since a lot of code I still
deal with is still in C and C++) and Lua's convention of using strings as
enums with interfacing with C.
Call it a programming bias.
> > 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!!!)
I saw the original code:
for _,A in ipairs { false, true } do
for _,B in ipairs { 'opt1' , 'opt2' , 'opt3' } do
...
as clouding my intent. The revision:
for A in bools() do
for B in list { 'opt1' , 'opt2' , 'opt3' } do
...
I feel clarifies rather than clouds my intent. The overhead (or rather,
abstraction) is the same---in both cases Lua is repeatedly calling a
function to return successive values, but the difference is in what values
are returned.
Names are also important, as you pointed out above.
And if you want an examle of mathematical inscrutiny, check out
https://www.youtube.com/watch?v=a9xAKttWgP4
which is an implementation of Conway's Game of Life in APL. [1]
> 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?
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.
-spc
[1] One line of APL, which can be seen here:
http://dfns.dyalog.com/c_life.htm