nil isn't as unique in Lua 4.1

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

nil isn't as unique in Lua 4.1

Peter Shook-3
I'd rather not have the boolean type because then there will be a need
for functions like Perl's 'defined' (to tell if a variable is not nil)
and 'exists' (to tell if a table has a value for a particular key).  How
else with you be able to tell if a variable is false or nil?

In Lua 4.0, it is simple to delegate to another table:

  x = t1[i] or t2[i]

If element i isn't in table t1, try t2.  But in 4.1, if t1[i] is false,
then this expression will access t2 when you don't really want it to.  I
don't want to see Lua start looking like this:

  $x = exists $t1{$i} ? $t1{$i} : $t2{$i} ;

- Peter

Reply | Threaded
Open this post in threaded view
|

Re: nil isn't as unique in Lua 4.1

Victor Bogado da Silva Lins-2
On Thu, 10 Jan 2002, Peter Shook wrote:

> 
> I'd rather not have the boolean type because then there will be a need
> for functions like Perl's 'defined' (to tell if a variable is not nil)
> and 'exists' (to tell if a table has a value for a particular key).  How
> else with you be able to tell if a variable is false or nil?
> 
> In Lua 4.0, it is simple to delegate to another table:
> 
>   x = t1[i] or t2[i]
> 

	In perl it works the same way, undefined variables "return" nil 
values, but there is a diference between undefined variable and variables 
that were defined with a nil value. 

	for instance (in lua syntax):

	a = nil

	print (a)
	print (b)

	if (a) then print ("a isn't nil\n") else print ("a is nil\n")
	if (b) then print ("b isn't nil\n") else print ("b is nil\n")

	if (defined(a)) then print ("a is defined\n") else print ("a is undefined\n")
	if (defined(b)) then print ("b is defined\n") else print ("b is undefined\n")


	----

	this program if it were perl would printout the following: 

	a is nil
	b is nil
	a is defined 
	b is undefined

-- 
[]'s Victor Bogado da Silva Lins
[hidden email]




Reply | Threaded
Open this post in threaded view
|

Re: nil isn't as unique in Lua 4.1

David Jeske-3
In reply to this post by Peter Shook-3
On Thu, Jan 10, 2002 at 12:37:35AM -0500, Peter Shook wrote:
> I'd rather not have the boolean type because then there will be a need
> for functions like Perl's 'defined' (to tell if a variable is not nil)
> and 'exists' (to tell if a table has a value for a particular key).  How
> else with you be able to tell if a variable is false or nil?

We could introduce a new operator to replace the overloading of
"or". Something like "ond" (On Not Defined):

  nil  or    2 -> true
  nil  ond   2 -> 2

  false or  2   -> true
  false ond 2   -> false

  nil or false  -> false
  nil ond false -> false

This seems better than having to do this all the time:

  a= if defined(b) then b else c end

However, don't get me wrong, I'll take any pain required if it means I
can actually store a false value in a table. Currently I have to make
EVERY if statement look like "if expr ~= 0", just so I can store 0
(i.e. false) values in a table.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: nil isn't as unique in Lua 4.1

Roberto Ierusalimschy-5
In reply to this post by Peter Shook-3
On Thu, 10 Jan 2002, Peter Shook wrote:

> I'd rather not have the boolean type because then there will be a need
> for functions like Perl's 'defined' (to tell if a variable is not nil)
> and 'exists' (to tell if a table has a value for a particular key).  How
> else with you be able to tell if a variable is false or nil?

  a == nil        x     a == false
  a[i] == nil     x     a[i] == false

-- Roberto


Reply | Threaded
Open this post in threaded view
|

RE: nil isn't as unique in Lua 4.1

Eric Ries
In reply to this post by Peter Shook-3
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"

It is // and "a // b" means the same as defined(a) ? a : b. So you can write
things like this:

a //= b // c // d

to give a the first defined value in this chain. In Lua 4.0, "or" works just
fine for this purpose, which I really liked. Maybe this new boolean type is
more trouble than it's worth?

Eric

> -----Original Message-----
> From: [hidden email]
> [[hidden email] Behalf Of Peter Shook
> Sent: Wednesday, January 09, 2002 9:38 PM
> To: Multiple recipients of list
> Subject: nil isn't as unique in Lua 4.1
>
>
>
> I'd rather not have the boolean type because then there will be a need
> for functions like Perl's 'defined' (to tell if a variable is not nil)
> and 'exists' (to tell if a table has a value for a particular key).  How
> else with you be able to tell if a variable is false or nil?
>
> In Lua 4.0, it is simple to delegate to another table:
>
>   x = t1[i] or t2[i]
>
> If element i isn't in table t1, try t2.  But in 4.1, if t1[i] is false,
> then this expression will access t2 when you don't really want it to.  I
> don't want to see Lua start looking like this:
>
>   $x = exists $t1{$i} ? $t1{$i} : $t2{$i} ;
>
> - Peter
>


Reply | Threaded
Open this post in threaded view
|

RE: nil isn't as unique in Lua 4.1

Roberto Ierusalimschy-5
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 ... ".

Notice that Lua already has a similar situation: the code

  (a and b) or c

is equivalent to "a ? b : c", provided that b is not nil (or false, now).
Again, frequently we know that b cannot be nil, and so the idiom works fine.

-- Roberto


Reply | Threaded
Open this post in threaded view
|

RE: nil isn't as unique in Lua 4.1

RLak
In reply to this post by Peter Shook-3
Roberto Ierusalimschy escribió:

> 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.

That's true, but it's also an obscure bug waiting to bite you. It's
actually quite
difficult to combine the need for simplicity with the desire for boolean
operators.

Personally, I would have prefered a different solution: leave "and" and
"or" as they are, and define "false" as a distinct value. That means that
false would be true, which I suppose would be counter-intuitive, but you
could get around that with a test for false (x ~= false, actually), which
could be a prefix operator. Actually, the only case in which you really
need false to be a non-nil but false value is when you want to stuff it
into a table, and you need to be able to distinguish between false, true
and unspecified: in other words, false is needed for three-valued logic.
That's fine, but we find ourselves without standard operators for
three-value logic, useful though they might be.


> 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 ... ".

So what about the default values question? In the case where I want a to
have a default,
I think that the following works, as an intellectual curiosity. I played
around with the three-valued truth tables, and I think that this captures
all the possibilities where a or default might be false.

   ... (a or (a == nil and default)) ...

This would not turn into my favourite idiom, I'm afraid.

What if I want to set a to the first of (a, f1(), f2(), ...) which has a
value without unnecessarily evaluating f() or g()? The above works for the
case where there is one f(), since default is only evaluated once, but I
can't pull that trick more than once because a needs to be evaluated twice.

Then I think in that case there is no expression solution, only the nested
if:
  if a == nil then
    a = f()
    if a == nil then
      a = g()
    end
  end

That's a lot wordier than
  a or f() or g()

(i.e. it requires some careful reading to know what's meant)

> > Notice that Lua already has a similar situation: the code

>  (a and b) or c

> is equivalent to "a ? b : c", provided that b is not nil (or false, now).
> Again, frequently we know that b cannot be nil, and so the idiom works
fine.

But presumably if you're using boolean values, one of the two cases you are
interested in is the one where b in fact is "false". I don't think there is
a good general solution with binary operators, though. Ternary operators
like C's ?: operator do handle the situation, but I'm not a huge fan of the
syntax.

Question: why are there no languages which define the following construct:

   value2 when condition other value2

which associates to the right quite readably:

   a = 0      when x < 0 otherwise
       1      when x < 1 otherwise
       foo(x)

Or do I just have a wierd mind?

R.



Reply | Threaded
Open this post in threaded view
|

Re: nil isn't as unique in Lua 4.1

Peter Shook-3
In reply to this post by Roberto Ierusalimschy-5
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

Reply | Threaded
Open this post in threaded view
|

RE: nil isn't as unique in Lua 4.1

jmckenn
In reply to this post by Peter Shook-3
>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.

The problem that false is there to solve is that nil is currently trying
to be two very different things - "false" and "doesn't exist".

Let's say you have a very lengthy computation that returns either "true"
or "false".  Since it takes such a long time to compute, you decide to
cache the results in a table.  Look up the parameter in the table - if
you get nil, then either you've already done the calculation and the
answer was "false", or you haven't done the calculation yet.

Or maybe you're implementing an object system with inheritance.  If a
field isn't in the child's member table, then look it up in the parent.
How do you store "false"?

Or there's Markus Huber's example: you want default values for function
parameters.  If the function gets nil for that parameter, then it can't
tell if the parameter was missing, or if the caller is trying to pass
"false".

Introducing a real false value means that nil can be "doesn't exist",
and nothing else.  It eliminates a lot of ambiguity.
-Virus scanned and cleared ok

Reply | Threaded
Open this post in threaded view
|

RE: nil isn't as unique in Lua 4.1

RLak
In reply to this post by Peter Shook-3
John McKenna escribió:

(Quoting Peter Shook)
> >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.

I agree with Peter here

> The problem that false is there to solve is that nil is currently trying
> to be two very different things - "false" and "doesn't exist".

Yes. The question is whether it is the right solution, since it is often
not
necessary to solve it.

> Let's say you have a very lengthy computation that returns either "true"
> or "false".  Since it takes such a long time to compute, you decide to
> cache the results in a table.  Look up the parameter in the table - if
> you get nil, then either you've already done the calculation and the
> answer was "false", or you haven't done the calculation yet.

function memoise(fn)
  local false = {}
  local memotag = newtag()

  local getter = function(t, k)
    local rv = rawget(t, k)
    return rv ~= %false and rv
  end

  local indexer = function(t, k)
    local val = %fn(k)
    t[k] = val or %false
    return val
  end

  local caller = function(t, k)
    return t[k]
  end

  settagmethod(memotag, "gettable", getter)
  settagmethod(memotag, "index", indexer)
  settagmethod(memotag, "function", caller)

  return settag({}, memotag)
end

If you know the memoised function really only returns true or false, there
is a
slightly simpler solution, but I find the above quite useful. It's possible
to
avoid the call to rawget in getter with a second level of indirection.
There is
also a solution for functions which might accept nil as an argument.

Memoising functions of more than one argument is a lot trickier, but that
wasn't
your question.

> Or maybe you're implementing an object system with inheritance.  If a
> field isn't in the child's member table, then look it up in the parent.
> How do you store "false"?

The above model works for this, too. I've really got to get around to
posting
my standard tag method library.

> Or there's Markus Huber's example: you want default values for function
> parameters.  If the function gets nil for that parameter, then it can't
> tell if the parameter was missing, or if the caller is trying to pass
> "false".

Define the global false={} and test for its existence. If that doesn't
appeal
to you, use the following:

function with_optional_second_argument(a, ...)
  local b = default
  if arg.n ~= 0 then b = arg[1] end
  -- do whatever you wanted to do
end

> Introducing a real false value means that nil can be "doesn't exist",
> and nothing else.  It eliminates a lot of ambiguity.

But it also creates an often unnecessary differentiation. I'd rather work
around the ambiguity when I recognise it.

Rici


Reply | Threaded
Open this post in threaded view
|

Re: nil isn't as unique in Lua 4.1

Roberto Ierusalimschy-5
In reply to this post by Peter Shook-3
On Thu, 10 Jan 2002, Peter Shook wrote:

> 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.

The 'or' operator never worked for boolean values. If nil (the false value
in 4.0) were among the valid values of "a", the expression "a or b" would
not give you the first "valid" (or defined) result.

The boolean type did not change that. (At least now we can speculate about
a "ond" operator ;-)

-- Roberto



Reply | Threaded
Open this post in threaded view
|

RE: nil isn't as unique in Lua 4.1

jmckenn
In reply to this post by Peter Shook-3
[hidden email] writes:

>Memoising functions of more than one argument is a lot 
>trickier, but that wasn't your question.

It wasn't a question.  It was an example.  I know that there are ways
to work around the problems that I was attempting to demonstrate, but
they are still work-arounds.

>Define the global false={} and test for its existence.

A "false" value that can't be used in boolean expressions is hardly a
solution.

I posted three examples where there is a need for a distinction between
"doesn't exist" and "false".  There are many others.  Yes, in each
particular case there's a way of working around it.  But in general
you'll need to come up with a new method every time you hit the
problem.  They're not intuitive.  They hide what the code is really
doing.

If there wasn't the need to keep compatibility with existing code, I
would argue that nil should not behave as "false" in expressions.  It
expresses an entirely different concept.  I find "value == nil" everywhere
I need to test for existence much less confusing than any of the other
options.  But I'm not a C programmer.  NULL == 0 == false only makes
sense if you have a C background.
-Virus scanned and cleared ok

Reply | Threaded
Open this post in threaded view
|

RE: nil isn't as unique in Lua 4.1

RLak
In reply to this post by Peter Shook-3
John McKenna escribió:

> It wasn't a question.  It was an example.  I know that there are ways
> to work around the problems that I was attempting to demonstrate, but
> they are still work-arounds.

"How do you store "false"?" looks like a question to me :-) I was trying
to be helpful.

> >Define the global false={} and test for its existence.

> A "false" value that can't be used in boolean expressions is hardly a
> solution.

It can easily be used in boolean expressions:

  if a ~= false or b ~= false then ... end

It just doesn't have the truth value you might expect it to have :-)

> I posted three examples where there is a need for a distinction between
> "doesn't exist" and "false".  There are many others.  Yes, in each
> particular case there's a way of working around it.  But in general
> you'll need to come up with a new method every time you hit the
> problem.  They're not intuitive.  They hide what the code is really
> doing.

I dunno. I came up with one way of dealing with it, and it works pretty
generally. I hide the mechanics in tag methods, so the code really does
what
it looks like its doing (as with other stuff hidden in tag methods). I
really
don't find that I have to work around the problem much, to be honest.

I think that in at least two of the examples you gave, you did not actually
want to
distinguish between nil and false. You wanted the underlying mechanics to
distinguish between nil and false. If you're memoising a boolean function,
for
example, you don't care whether the memoiser knows that the answer is false
or
has to work it out. You just want an answer which is true or false. (And
that's
why I wrote the memoiser generator that I outlined). Similarly, when you're
doing
inheritance, you (as a consumer) don't care whether the nil/false was
direct or
inherited. In both of these cases, the visibility of that fact out would
defeat
the point of isolating the mechanics from the use.

You might, of course, want to know (for any value, not just nil/false)
whether
it was going to take a long time to compute or not -- say, in an
interactive
environment. But that is a separate interface. ("known", maybe). I have a
memoiser version which does that, too, if you're interested.

Now, Markus Huber's example is more interesting. He wants to know whether
or not an argument is false or omitted, so he can provide an "explicit
false".
Adding "false" as a false value means that I can no longer simply test for
a defaulted parameter, though -- now I *have* to consider the case that it
might be an explicit false. So a workaround is required in either case: the
questions are, which cases are more common, and which base solution is more
elegant. I argue that the "single-nil" solution is more elegant, and the
cases
where you need an explicit false are rarer than the cases where you don't.

It is, in fact, one of my pet annoyances with the base Lua library that
some
functions actually do distinguish between explicit nil and the absence of a
parameter. They shouldn't, and it would be easier to call them if they
didn't.

In summary, I suggest that the "problem" you present is not that there is
only
one false value in the system; rather it is that you cannot store such a
value
in a vanilla table. The solution to that problem is to come up with a table
which accepts nil as a value, and I'm quite happy to have done so.

> If there wasn't the need to keep compatibility with existing code, I
> would argue that nil should not behave as "false" in expressions.  It
> expresses an entirely different concept.  I find "value == nil"
everywhere
> I need to test for existence much less confusing than any of the other
> options.  But I'm not a C programmer.  NULL == 0 == false only makes
> sense if you have a C background.

A low blow. I do program in C, but I don't have a "C background". I have a
Lisp background. But there are lots of languages other than Lua in which
the
absence of a value is indistinguishable from a boolean "false". And there
are
always some people who complain about that and some who will defend it to
the
death. So there is probably no resolution to the question.

Perl's flexibility about what is "false" has burned me a lot of times,
though,
and is on the list of why I will probably not use Perl anymore.




Reply | Threaded
Open this post in threaded view
|

RE: nil isn't as unique in Lua 4.1

Eric Ries
In reply to this post by jmckenn
Maybe I am just dense, but why does this require that "not nil" and "not
false" be the same thing? If you're trying to use a non-nil value to cache a
"false" response, why not just make up your own value and then test for it
explicitly? It seems to me that the road to simplicity lies in having only
one value that the boolean operators understand as "nil/false"

Eric

> -----Original Message-----
> From: [hidden email]
> [[hidden email] Behalf Of John Mckenna
> Sent: Friday, January 11, 2002 2:36 AM
> To: Multiple recipients of list
> Subject: RE: nil isn't as unique in Lua 4.1
>
>
> >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.
>
> The problem that false is there to solve is that nil is currently trying
> to be two very different things - "false" and "doesn't exist".
>
> Let's say you have a very lengthy computation that returns either "true"
> or "false".  Since it takes such a long time to compute, you decide to
> cache the results in a table.  Look up the parameter in the table - if
> you get nil, then either you've already done the calculation and the
> answer was "false", or you haven't done the calculation yet.
>
> Or maybe you're implementing an object system with inheritance.  If a
> field isn't in the child's member table, then look it up in the parent.
> How do you store "false"?
>
> Or there's Markus Huber's example: you want default values for function
> parameters.  If the function gets nil for that parameter, then it can't
> tell if the parameter was missing, or if the caller is trying to pass
> "false".
>
> Introducing a real false value means that nil can be "doesn't exist",
> and nothing else.  It eliminates a lot of ambiguity.
> -Virus scanned and cleared ok
>


Reply | Threaded
Open this post in threaded view
|

Re: nil isn't as unique in Lua 4.1

David Jeske-3
In reply to this post by RLak
On Fri, Jan 11, 2002 at 12:30:05PM -0500, [hidden email] wrote:
> I dunno. I came up with one way of dealing with it, and it works
> pretty generally. I hide the mechanics in tag methods, so the code
> really does what it looks like its doing (as with other stuff hidden
> in tag methods). I really don't find that I have to work around the
> problem much, to be honest.

The idea of changing every if statement to include tests for some new
"false" table does not feel like a solution to me. That's basically
what I do now with != 0. Also, tag method tricks which negatively
impact the performance of looking up values in tables also do not feel
like solutions.

> I think that in at least two of the examples you gave, you did not
> actually want to distinguish between nil and false.

This really isn't to distinguish between nil and false, it's to be
able to store a 'logically false' value in a table, for one of many
reasons.

For those who don't like introducing boolean values, there are at
least two other solutions to this problem.

1) One way to look at it is that it's this 'unstorable nil' which is a
problem. Afterall, the C interface can tell the difference between a
missing paramater and LUA_T_NIL in a variable argument list, why can't
lua?

One could solve the storable nil problem by removing the semantic that
a["foo"] = nil, deletes the table value, and instead introduce a 'del
a["foo"]' operation. Then there would be a new existance test, such as
Python's a.has_key("foo"), or something similar.

2) Another way to look at it is that the boolean tag methods are
missing. There are tag methods for "add","sub","mul", and "div", but
why not "and", "or", and "not"? If there existed, then those of us who
need a false value could just make a special table and put in new tag
methods to honor that table as a false value. 

--

Personally, I think that either introducing a false value, or (#2)
above, introducing boolean tag methods both solve the problem pretty
well.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + [hidden email]

Reply | Threaded
Open this post in threaded view
|

memory tracking troubles

Eric Ries
In reply to this post by Eric Ries
Hello all. I am running an embedded lua interpreter in a limited-memory
environment. I have found that, after running certain scripts, I run out of
memory. I am able to track all allocations on the system, but this only
tells me that the memory was allocated by luaM_realloc(). Is there any way
to get Lua to tell me what it is using each allocation for? Any suggestions?

Eric


Reply | Threaded
Open this post in threaded view
|

Re: nil isn't as unique in Lua 4.1

Peter Shook-3
In reply to this post by David Jeske-3
David Jeske wrote:
> 
> We could introduce a new operator to replace the overloading of
> "or". Something like "ond" (On Not Defined):

The idea is okay with me, but I'd prefer a name like 'otherwise',
'alterno', 'alter', or 'alt'.

- Peter

Reply | Threaded
Open this post in threaded view
|

RE: memory tracking troubles

Joshua Jensen
In reply to this post by Eric Ries
> Hello all. I am running an embedded lua interpreter in a 
> limited-memory environment. I have found that, after running 
> certain scripts, I run out of memory. I am able to track all 
> allocations on the system, but this only tells me that the 
> memory was allocated by luaM_realloc(). Is there any way to 
> get Lua to tell me what it is using each allocation for? Any 
> suggestions?
> 
> Eric

The LuaState distribution has this built into it.

http://workspacewhiz.com/Other/LuaState/LuaState.html

See the section Memory Allocators of the above page.  The name of the
allocation is passed into every allocation, and from there, you can keep
track of it.  This is accomplished through the macros, luaM_setname()
and luaM_setnameif() in the Lua code (which don't exist in the main Lua
distribution).

Josh


Reply | Threaded
Open this post in threaded view
|

RE: nil isn't as unique in Lua 4.1

Eric Ries
In reply to this post by David Jeske-3
Agreed. Both proposals (esp. #2) strike me as superior to introducing a new
special value "false" to go with the special value "nil"

Eric

> -----Original Message-----
> From: [hidden email]
> [[hidden email] Behalf Of David Jeske
> Sent: Friday, January 11, 2002 12:30 PM
> To: Multiple recipients of list
> Subject: Re: nil isn't as unique in Lua 4.1
>
>
> On Fri, Jan 11, 2002 at 12:30:05PM -0500, [hidden email] wrote:
> > I dunno. I came up with one way of dealing with it, and it works
> > pretty generally. I hide the mechanics in tag methods, so the code
> > really does what it looks like its doing (as with other stuff hidden
> > in tag methods). I really don't find that I have to work around the
> > problem much, to be honest.
>
> The idea of changing every if statement to include tests for some new
> "false" table does not feel like a solution to me. That's basically
> what I do now with != 0. Also, tag method tricks which negatively
> impact the performance of looking up values in tables also do not feel
> like solutions.
>
> > I think that in at least two of the examples you gave, you did not
> > actually want to distinguish between nil and false.
>
> This really isn't to distinguish between nil and false, it's to be
> able to store a 'logically false' value in a table, for one of many
> reasons.
>
> For those who don't like introducing boolean values, there are at
> least two other solutions to this problem.
>
> 1) One way to look at it is that it's this 'unstorable nil' which is a
> problem. Afterall, the C interface can tell the difference between a
> missing paramater and LUA_T_NIL in a variable argument list, why can't
> lua?
>
> One could solve the storable nil problem by removing the semantic that
> a["foo"] = nil, deletes the table value, and instead introduce a 'del
> a["foo"]' operation. Then there would be a new existance test, such as
> Python's a.has_key("foo"), or something similar.
>
> 2) Another way to look at it is that the boolean tag methods are
> missing. There are tag methods for "add","sub","mul", and "div", but
> why not "and", "or", and "not"? If there existed, then those of us who
> need a false value could just make a special table and put in new tag
> methods to honor that table as a false value.
>
> --
>
> Personally, I think that either introducing a false value, or (#2)
> above, introducing boolean tag methods both solve the problem pretty
> well.
>
> --
> David Jeske (N9LCA) + http://www.chat.net/~jeske/ + [hidden email]
>


Reply | Threaded
Open this post in threaded view
|

RE: nil isn't as unique in Lua 4.1

Enrico Colombini
> One could solve the storable nil problem by removing the semantic that
> a["foo"] = nil, deletes the table value, and instead introduce a 'del
> a["foo"]' operation. Then there would be a new existance test, such as
> Python's a.has_key("foo"), or something similar.

If the problem here is only that of 'existing but empty' table entries,
this seems to me a simpler, cleaner solution than having multiple, slightly
different, 'false' values.
(anyway, I am only a C programmer that always felt comfortable with 0 ==
false)

  Enrico