Re: Undefined variables returning nil

[William Ahern <william@...>]

On Wed, Mar 20, 2013 at 12:19:24AM -0600, William Sumner wrote:
> On Mar 19, 2013, at 10:51 PM, Coda Highland <chighland@gmail.com> wrote:
> > 
> > No one disagrees it's a legitimate issue, but do you blame C for a
> > lack of error reporting for uninitialized memory accesses, or do you
> > use Valgrind to find them? Not every solution has to be implemented in
> > the language core. It's completely acceptable for an external tool to
> > provide techniques to resolve the problem.
> 
> Going by the responses, I think many actually do disagree that it's a legitimate issue, but to answer your question: lots of people blame C for its error-prone access to raw memory; in fact, it's one of the motivations for using Lua! More to the point, C doesn't detect uninitialized memory accesses because it's a systems language with different requirements than that of an embedded scripting language targeting non-professional programmers. C's lack of error-reporting in that case has nothing to do with Lua's lack of error-reporting in this one.
> 
> One's response might be to take that statement and say, "Well, Lua has
> different requirements from what you're wanting", which is in the vein of
> what has been said by others, but there's really been no explanation of
> what the key requirement is that makes it a necessity to silently evaluate
> to nil instead of report the error.

Because conflating nil and void is convenient. For the same reason that
having a single table type is convenient. Elegance often comes from allowing
ambiguity to be resolved by context rather than at a syntactical level. It's
as simple as that.

Consider

	local x = (function() return end)()

and

	local x = (function() return nil end)()

Should these two be treated differently? The runtime could throw an error
when the return list doesn't match. But if that was the case, then you
couldn't do stuff like:

	local f = function() return end

	function wrap(f, ...)
		return f(...)
	end

The return assignment would trigger an assertion in the wrong place. Or
should we just special case this?

That issue is identical to the problem of looking up a non-existent key in a
table.

> If the only explanation is that it's a design decision, then what I'm
> arguing is that it's an unsafe one. I understand the concept being
> presented that tables start out with all possible keys set to nil, but it
> doesn't seem worth it to maintain that facade given the drawbacks
> encountered in practice.

You still haven't convincingly explained how it's unsafe, and in any event
your alternative is not much better. At best it triggers errors earlier.
This may be more convenient when debugging, but it will also cause problems
for other people like myself who use the ambiguity of Lua's nil value to
simplify and defer error checking. It allows you to write or add
intermediate code which can perform certain operations on the non-existent
value without if-then-else trees. As long as you keep this is mind, it can
be a very powerful tool to simplify code and lessen the burden of error
checking. The Lua C API benefits from this immensely.

(A similar example in C is the behavior of free() and realloc(). Both permit
passing NULL, which in just those two instances alone dramatically reduces
the complexity of many common patterns in C. That some people are unaware of
this feature and don't make use of it to simplify their code doesn't reduce
its value to me one iota.)

I noticed that you left out a critical quote from the lua-checker page. You
quoted

	In practice, Lua programs over (say) 1000 lines tend to accumulate
	these kinds of problems, making debugging difficult.

but the remainder of that paragraph was

	A standard Lua practice to deal with undefined global variables is
	to install a special 'get-value' handler on the global variable
	table that warns when undefined globals are accessed. This is of
	limited benefit because problems are still only detected at
	run-time.

Note that your alternative doesn't change the fact that run-time errors are
more difficult to track down than compile-time errors. This is by far the
greater part of the problem, so the value of your proposal is quite
marginal.