Re: nil isn't as unique in Lua 4.1

[Peter Shook <peter.shook@...>]

Roberto Ierusalimschy wrote:
> 
> On Thu, 10 Jan 2002, Eric Ries wrote:
> 
> > I'm afraid that, if Lua goes down this path, we will have the need for
> > Perl6's "defined-shortcut-operator" which works "like || but with a twist"
> 
> I think that, more often than not, you know what type of object you
> are expecting. So, if you are expecting numbers, or tables, or strings,
> you still can use the "or" to select the first "defined" value.
> 
> In the few cases that a false is among the possible outcomes, then we
> will have to go through the pain of writing "if a == nil then ... ".

I'd agree that most of the time it isn't a big deal.  I'm just a little
saddened that the once beautifully simple 'or' operator is now somewhat
tarnished, and there isn't really a compelling reason or need for a
boolean type.

I look at lexically scoped and eventtable and I think "WOW, that's
great. That will fix a whole bunch of nasty things in my code."  I look
at false and I thing "What for?".  I guess false just isn't that useful
for me.  I just hope you don't go and add 0, "0" and "" to the list of
false values.


One other thing I find peculiar is that the second argument of concat
and eventtable cannot be nil (or false).

This is a pain when you want to wrap concat in another function.  You
must say:

function join( t, sep ) 
  -- whatever other stuff
  sep = sep or ''  -- because nil won't work
  return concat( t, sep )
end

Or if you want to save and restore the eventtable for some reason.

function dosomethingspecial( t )
  local et = eventtable(t) or {}  -- need 'or {}' because nil won't work
  eventtable( t, somethingnew )
  -- whaterver other stuff
  eventtable(t,et)
end


- Peter