Re: Idea. Removing nils from the language.

Hi,

The idea is to remove from the syntax and from the virtual machine. Since nil doesn't exists, mathematically it's not possible to have nil errors. nil must be replaced, but are replaced with default sensible (from the program point of view) values. Looks strange but it's always possible to replace a nil with a default value. Actually the program is always trying to solve an algorithm and nil, being and undefined variable that can not even be read (just compared), will not help at all to solve the problem. Some algorithms can not have a solution for a given set of input values (for example searching the value of a non-existing key in an array). In such case exceptions are raised. It's the way the code has to indicate "Sorry, I can't continue since I don't know what to do next".

Regards,

Enrique

On Fri, Jan 9, 2015 at 6:24 PM, Udo Schroeter <udo.schroeter@gmail.com> wrote:

Even in your dialect, accessing a non-existent variable would still raise the equivalent of a nil error, at runtime. Only a full-on static type system would enable you to check code meaningfully at compile time, and as you said you'd have to incorporate tables into it somehow as well.

I don't think Lua would gain anything just by leaving out the nil. Nil is a mechanism, and you're going to have to replace that mechanism with something else entirely. There are languages that do this.

I was on a similar quest, but ended up doing it very differently. In my personal dialect, I have disallowed the incidental declaration of global variables. Declarations are all local/lexical and assigning a value to an undeclared variable is a runtime error. Combined with things that make some nil checks superfluous, I'm quite happy with the result.

Anyway, I'd say, go for it! Try out new things!

On Fri, Jan 9, 2015 at 6:08 PM, Enrique Arizón Benito <enrique.arizonbenito@gmail.com> wrote:
Hi all,

I've been using Lua in my last project and I found it incredible useful, allowing to reuse the same code on Windows, Android and Linux. (Cross-compiling was a different history :) ). Thanks all the developers for your work. You rocks!

I also observed that the source code of Lua is incredible small when compared to other languages, making it ideal to test new features with no much effort.

Apart of thanking developers for their efforts, my mail is to comment next idea:

For a lot of years I've been interested in a language that fix "the biggest bug in History", the invention of null (nil) references (http://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions). I think Lua can be a perfect laboratory to experiment with null removal.

In practice, it all consist in removing the "nil" from the language syntax and the virtual machine.

The theoretical advantages of doing this could be:

- Fewer bugs, since there will be no nulls anywhere, anymore, there will be no nulls related errors (referencing undeclared variabled) either.

- Removing the null forces to assign a default value at variable initialization. That means that the distinction between dynamic and statically typed languages vanish, since we can consider a variable as dynamic with the type "placed" on the value, or we can consider the type of the variable to be that of the value at initialization (by just taking the sensible approach that a variable doesn't change its type after initialization). This would also simplify jit compilers, since there will be no need for complex run-time tracers. In fact code can be pre-compiled since the type can be deduced from the syntax. (This is not exactly true, since there is still a problem with dynamic object like lists that can contain any type of object and probably they must be split in two, those with unique types for key/values for which we can force static typing and those with dynamic types for key/values)

- Simpler and faster code, since there is no need to repeatedly check if a variable is nil.

- Easier to read code. Many times 'nil' are used as "marks" to indicate implementation "details". For example it's much easier to read/understand a code like:
if (pointer == end_of_list) ...
than
if (pointer == null) ...

The main disadvantages I see are:

- No backward compatibility. APIs using/returning nils must be changed.

- Probably slightly higher RAM usage, since there is a need to define default objects -a good programming pattern anyway-, and also "mark" object to indicate "end-of-list" and other internal representation details.

I already took a look at the source code and managed to remove nil from the syntax , actually removing just the 'nil' token from the parser was the easy part, but juggling with the virtual machine internal details is something that escapes to my knowledge at this moment and I have not much free time to work on it, so I post it here for anyone with more knowledge about the internal details that could be interested.

Best Regards,

Enrique Arizón Benito