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.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.Anyway, I'd say, go for it! Try out new things!On Fri, Jan 9, 2015 at 6:08 PM, Enrique Arizón Benito <firstname.lastname@example.org> wrote:if (pointer == null) ...thanif (pointer == end_of_list) ...- 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:- Simpler and faster code, since there is no need to repeatedly check if a variable is nil.- 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)- Fewer bugs, since there will be no nulls anywhere, anymore, there will be no nulls related errors (referencing undeclared variabled) either.In practice, it all consist in removing the "nil" from the language syntax and the virtual machine.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.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!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.
The theoretical advantages of doing this could be: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