Re: About a week with LUA_NOCVTN2S and LUA_NOCVTS2N

[Sean Conner <sean@...>]

It was thus said that the Great Andrew Starks once stated:
> I compiled Lua with the LUA_NOCVTN2S (no coercion from numbers to
> string) and LUA_NOCVTS2N (same, but from string to numbers).

  [ ... ]

> 5: I like programming with it and will always have it turned on.

  What I find annoying is that lua_isnumber() and lua_isstring() return true
when it's *either a number or a string!*  I've been bitten by that enough
times you'd think I'd have learned by now, but no ... I still get bit from
time to time.

  But, even though I might be prompted to define LUA_NOCVTN2S or
LUA_NOCVTS2N, doing so breaks the C API and C modules that rely upon the Lua
5.1/5.2 behavior break in subtle ways.  I would think that the manual for
Lua 5.3 should mention that
lua_isstring()/lua_isnumber()/lua_tostring()/lua_tonumber() might have
different semantics.

> I like it because I suffer from *Abstraction Anxiety*: A general fear
> of abstractions, especially ones that perform magic tricks without
> explicit instructions to do so. (I'm still working on that
> definition... I think it's very common amongst Lua folks)

  You're not alone.  There's the famous Joel Spolsky article "The Law of
Leaky Abstractions" [1], and this lesser known bit, "Does Abstraction
Scale?" [2]  I know in my own code, I try to avoid needless abstractions,
but sometimes, I fall into the trap.

  At work, I'm in the process of enumerating test cases for a regression
test.  I wrote code so that I could do:

	for A in bools() do
	  for B in list { 'variation-a' , 'variation-b' , 'variation-c' } do
	    for C in list { 'c1' , 'c2' } do
	      for D in bools() do
	        ...
	        
which closely minics the actual language used to describe the test
conditions:

	A can be on or off
	B can be variation-a, variation-b or variation-c
	C can be either c1 or c2
	D can have two options
	...
	
  Sure, I could have written those as:
  
	for _,A in ipairs { false , true } do
	  for _,B in ipairs { 'variation-a' , 'variation-b' , 'variation-c' } do
	    for _,C in ipairs { 'c1' , 'c2' } do
	      for _,D in ipairs { false, true } do
	      ...
	      
but a) it's more typing [3] and b) it doesn't express what is going on
succinctly enough.  So what if I had to write a few functions (bools() and
list()) to gain this, ipairs() is already a function so it's not like I'm
loosing any performance over this.

  I should also note that I'm the only Lua programmer in the company (and
the other programmers in my department tend to use Perl or Python as their
"to-go" scripting language).

  -spc (and that '...' lists about another seven conditions)

[1]	http://www.joelonsoftware.com/articles/LeakyAbstractions.html

[2]	http://thoughtstorms.info/view/doesabstractionscale

[3]	Which, oddly enough, is an argument I almost never make.  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.