Re: Iteration and nils

[Thomas Lauer <thomas.lauer@...>]

"Chris Swetenham" <cswetenham@frontier.co.uk> wrote:
> > A sensible (IMHO) remedy has already been suggested a few times: there
> > should something *officially sanctioned* that means "I have a value
> > without actually having a value". Call it table.hole, call it sonofnil,
> > call it null (the latter had to be reserved words), call it what you
> > will: I think once such a "value" is a standard feature of Lua and used
> > correctly as such, many problems connected with nil will simply go away.
> 
> If I am not mistaken, JavaScript has both "null" and "undefined" values; 
> "undefined" has the same role as "nil" does in Lua, and "null" has the 
> meaning you suggest. It seems to me that introducing a new "null" value as 
> you suggest would be an elegant way of solving the problems of "nil" without 
> introducing any new ones, with the only small drawback that "null" becomes a 
> reserved word.

Similar situation in Perl, where keys in hashes, for instance, can be
undefined or defined (and queried as such) but still uninitialised.

> It would be possible to simulate by simply adding "null = {}" somewhere, but 
> then this would evaluate to "true" in a boolean context, so I think it would 
> be best if it were added to the base language.

The main point is that such a 'null' (or a similar construct) can only
ever work reliable if it's in the language, i.e. everybody can (and
will) use it as a matter of course. Then one can be reasonably sure that
modules, libraries and other 3rd party code share the same idea of
'undefined'.

Homegrown solutions are good for many (if not most) things, but this
seems to me to be a central point in the language... perhaps not unlike
the true/false discussions which took place long before I even knew
there's a language called Lua.

-- 
cheers  thomasl

web : http://thomaslauer.com/start