RE: Propsoal: a lua dialect without nil

Kristofer Karlsson wrote:

> I think the source of problems with nil isn't its

> existence, but its double meaning.

> The two senses of nil - nothing is stored here,

> and a value that is unlike other values - …

joao lobato wrote :

> 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

Maybe you should/could consider nil only as « a value that is unlike other values », not as « nothing is stored here ».

It has a type (type(nil) == "nil"), it can be assigned to a variable (local var = nil), it can be passed as a parameter (print(nil)) and it can be returned from a subroutine (function() return nil end).

(So, according to the Wikipedia definition, it is a first-class value: http://en.wikipedia.org/wiki/First-class_object)

It is unlike other values NOT because of its type, but because of its uses.

- It has only one value (boolean has only two values)

- It is the value given when we don’t know what else to give (not defined, unknown value, an error occured, …)

- Tables don’t store nil values, and accessing an undefined table member give nil (so, as storage in lua is done with tables most of time, nil is considered as 0-sized for storage)

- …

You could compare nil to the character ‘\0’ in a string, which is a common typed value (char) but has a special meaning (end of string).

As strlen(some_string) give the index of the first ‘\0’ character in C, #some_table give the last non-nil value in Lua (within some conditions J).

But I agree that it’s easier to think (and to teach) that nil means « nothing is stored here », but it’s the same (no double meaning). ;)

Best regards, Julien Duminil

De : lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] De la part de Kristofer Karlsson
Envoyé : mardi 15 février 2011 13:41
À : Lua mailing list
Objet : Re: Propsoal: a lua dialect without nil

I think the source of problems with nil isn't its existence, but its double meaning. The two senses of nil - nothing is stored here, and a value that is unlike other values - are separate in most other languages. For example, in Python, "nothing is stored here" is signified by raising an exception, and "value that is unlike other values" is signified by None. The problems with nil rise from the fact that it has to handle both cases.

So, I don't think getting rid of nil is the answer. I think the answer lies in a stronger way of defining which values are actually defined, beyond "does it equal nil." I'm borrowing from Python here, but "in" and "del" keywords for testing whether a key is actually *defined* in a table (i.e. "3 in t") and deleting keys from a table (i.e. "del t[3]") might be useful for this. This obviously isn't a complete solution to the problem, but it would definitely sort out a lot of the confusion.

--
Regards, Matthew Frazier

Python does both:

x = map.get("foo") # returns None if not found
x = map["foo"] # raises error if not found

Not sure if this is good or not.

I actually think Luas map model is easier to grasp than Pythons.
In Lua, a table is simply a map from key to value, where value can be anything including nil. There is no hard coded concept of exists or not, that's up to interpretation.

In Python, I can do:
t = dict()
None in t # gives False
t["foo"] # error
t.get("foo"] # gives None
t["foo"] = None
t["foo"] # now gives None
None in t # still gives False

This makes it confusing. Python seems to use None both as a real value and as indicator of absense - since "None in t" will never give true.