[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: lists with nil play nice for Lua 5.2
- From: Asko Kauppi <askok@...>
- Date: Tue, 31 Jul 2007 22:09:06 +0300
Then let's call it
and let the Lua parser loosen up on the keywords a bit, to allow:
and instead of being itself a table by type, can we have its type()
give 'nil'? (...hearing mumbling? Why not? )
The thing is, in iteration the type itself may be a decisive factor
on how to interpret the values, and thus a 'table.nil' having any
normal type should best be avoided. Also, if Lua were to go this
road, the natural step would be to table.nil == nil in value comparison.
Irayo kirjoitti 31.7.2007 kello 20:20:
Norman Ramsey wrote:
Perhaps Lua 5.2 can address the policy disorder by
providing a value 'table.hole' whose sole purpose is to be distinct
from every other value (including nil) :-)
This makes the most sense to me out of any of the other solutions.
Nil in tables is not "nothingness"--it means, technically, that the
key is non-existent. So, asking Lua if a specific table element is
nil is, in essence, asking if that element is non-existent.
Setting a table element to nil specifically is just *telling* Lua
that the element doesn't exist. Lua doesn't handle non-existent
elements because they *don't exist*. So you can't expect to be
able to tell Lua that an element doesn't exist and then have it
know that you meant that the element existed, but was blank.
People use the value 'nil' in such a way as to say "nothing".
'blah = nothing'. But if you're writing that with a nil, you're
telling Lua that blah doesn't exist. A "hole" or "blank" value, as
Norman suggested, addresses this by being able to differentiate
t = nil; -- a nonexistant element, and
t = table.hole; -- an element that exists, but has no properly
#t = 2, because 'hole' is has a value. Of course, I rather think
we could come up with a more friendly name than "hole"--like maybe
"blank". I dunno.
Users can continue using nil if they want, and use all the work-
arounds to have iterators work in sparse tables, which means it's
fully backward-compatible. Nothing changes except the addition of
another element to the table library (as far as I know). Other
users can properly use new functions.
It may also be useful to define a function in such a way that f(a)
is "(a==nil) or (a==table.hole)", so that you can check whether a
value is nil *or* a hole.
As always, I'm not a Lua expert and I don't know what most people
in the community are looking for; this just seems to be a very
simple and elegant solution to a long-lasting problem. Feel free
to get all up in my grill if you disagree--I want to see what