Re: Propsoal: a lua dialect without nil

[Luiz Henrique de Figueiredo <lhf@...>]

> nil is not a first-class value nor is it meant to be: you can't store nils
> in tables and that's a feature, not a bug.

Here's is my personal take on this: nil *is* a first-class value because
it can be stored in variables and tables and it can be passed to and
returned from functions. In all these contexts, nil means "nothing": for
instance, when you set var=nil, then var contains nothing, as you can
check when you read var.

The only restriction is that nil cannot be a table *key*, because you
cannot put something in a "nothing" box or position. This is consistent
with t[nil] being nil on reads because "nothing" is at nowhere.

The role of nil in boolean expressions is also clear from the interpretation
of "if cond then": if cond is something and is not false then... Since nil
is nothing, is must be treated as false.

Now, the thing that seems confusing to some is that nil seems to be lost
in varargs. The problem here is that varargs is not a container and so
it has no "name" for where to put nils (or anything else). As soon as
you give names to what is "in" the varargs, everything is fine. Consider:

	function f(x,...)
		local a,b,c=...
	end
	f(1,2,3) -- a gets 2, b gets 3, c gets nil

Some have argued that varargs is not a first-class value and they definitely
have a point. The select function tries to address this but fails because
it is not a language construct and it is a bit klugdy to use.

But I most definitely see nil as playing a clear role that does not need to
be fixed in any way.