lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 02/15/2011 05:20 AM, Axel Kittenberger wrote:
Nil is not a first class value. It has a recurring scheme of cases
where it has a strange kind of double-meaning, nil as variable not
there, and nil as a result of something not-being there stored in a
variable, now not there. Same with recent discussions what to do if
inserting nil into a list. Or people requesting how to differ if a
function was called without a parameter or with nil as parameter. This
can be achieved in lua with select('#', ...) and only highlights more
the funky meaning of nil. This problems might exist more in heads of
the coders than the language/interpreter, since when learned all the
details how nil behaves you can work with it. However, even if so, a
good programming language should be aimed just as much to the heads to
coders than of cpus - thats all what in my opinion object oriented
programming was about - to better fit in the way we humans think
natively. The issue most directly on hand is type-safeness and let
errors happen where they occur instead of returning nil and error
later. local condition = some_function(); if conditonn then  --- will
always silently fail, even if some_function returned true.

I think the source of problems with nil isn't its existence, but its double meaning. The two senses of nil - nothing is stored here, and a value that is unlike other values - are separate in most other languages. For example, in Python, "nothing is stored here" is signified by raising an exception, and "value that is unlike other values" is signified by None. The problems with nil rise from the fact that it has to handle both cases.

So, I don't think getting rid of nil is the answer. I think the answer lies in a stronger way of defining which values are actually defined, beyond "does it equal nil." I'm borrowing from Python here, but "in" and "del" keywords for testing whether a key is actually *defined* in a table (i.e. "3 in t") and deleting keys from a table (i.e. "del t[3]") might be useful for this. This obviously isn't a complete solution to the problem, but it would definitely sort out a lot of the confusion.

Regards, Matthew Frazier