Idea. Removing nils from the language.

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

Idea. Removing nils from the language.

Enrique Arizón Benito
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
Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Javier Guerra Giraldez
On Fri, Jan 9, 2015 at 12:08 PM, Enrique Arizón Benito
<[hidden email]> wrote:
> 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


I think this critique only applies to type systems where NULL is a
special value of each type, and in C-like languages using as a pointer
(or reference) can crash the whole program.  calling a design flaw "a
bug" is just sensationalism.

In Lua (and several other dynamic type languages) nil is a separate,
single valued type, you don't have "NULL pointers", not even "NULL
tables" or "NULL numbers"  just that as usual you can get values of
any type at any point.  Not having nil wouldn't avoid you to get a
number when you'd like a table, or viceversa.  you'd still have to
check for boundary cases.

--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Steven Degutis
In reply to this post by Enrique Arizón Benito
What would happen if you accessed a key in a table that it doesn't
contain? Right now it returns nil. What would it do instead if we
removed nil?

Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Rob Kendrick-2
On Fri, Jan 09, 2015 at 11:21:40AM -0600, Steven Degutis wrote:
> What would happen if you accessed a key in a table that it doesn't
> contain? Right now it returns nil. What would it do instead if we
> removed nil?

Be like Python, and drive programmers world-over by it being an error
condition, requiring every access to be wrapped in a check or exception
trap.

A side effect of this will be a notable increase in balding.

B.

Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Udo Schroeter
In reply to this post by Enrique Arizón Benito
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Steven Degutis
Quoth Udo Schroeter:
> 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.

Why create a Lua dialect for this? In Lua 5.2 and up, you can do this
more simply by creating a new metatable for _G and setting its
__newindex to raise an error.

Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Udo Schroeter
> Why create a Lua dialect for this? In Lua 5.2 and up, you can do this
> more simply by creating a new metatable for _G and setting its
> __newindex to raise an error.

No, not for this specifically, it was just one thing I wanted to do.

On Fri, Jan 9, 2015 at 6:47 PM, Steven Degutis <[hidden email]> wrote:
Quoth Udo Schroeter:
> 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.

Why create a Lua dialect for this? In Lua 5.2 and up, you can do this
more simply by creating a new metatable for _G and setting its
__newindex to raise an error.


Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Enrique Arizón Benito
In reply to this post by Javier Guerra Giraldez
Hi Javier,

Actually the opposite applies. C language handle *REAL* memory directly.
A NULL pointer in C is just a pointer whose value is 0, and 0 is a *REAL* memory address.
Most desktop&servers CPU's will consider an access to the 0 address a programming mistake and raise a SEGFAULT, but that's just a design decision. 0 is just one in a set of forbidden address as many other (upper memory belonging to kernel space  for example or "gaps" between stack segment and code segment).
In fact, in microcontrollers, the "0" address can be read/written normally and it's even possible that some of them use it mapped to I/O ports.

In high-level languages NULL is, as you said, is a separate, single valued type.
What's the utility of such value? There are just two possibilities.
The first one is to declare a variable without forcing to initialize it. For sort programs this can work if we are sure that it will be initialized later on, before reading it.
In bigger programs it's a wrong pattern. A program can always use default values of a given type instead of a NULL, and that automatically fixes many potential errors.

The second use of NULL, is to use it internally (in the Lua VM) as a "mark" to indicate special values like "end of list", "end of parameters", ... This NULL is used just in if conditionals to continue/stop some function.
In such case, it's also possible to replace it with some other more intuitive values. In the lua VM C code for example it would be possible for example, to declare
TValue endOfList;


And later on, just use code like:
if (&objectInstance == endOfList) { /* we are finished reading the list */  ... }

In the Lua VM C code, there is not need to assign any type to those "mark" variables (not need to create a new NULL value), since they will never be read, only its address in memory will be compared, but the code will be more maintanable and easier to read.

The important idea is that nil can always be replaced. It just adds "entropy" to the code. I have a post in my blog explaining the problem with some examples:
http://chuletario.blogspot.com.es/2011/05/kill-null-killen-all.html

Regards,

Enrique

On Fri, Jan 9, 2015 at 6:20 PM, Javier Guerra Giraldez <[hidden email]> wrote:
On Fri, Jan 9, 2015 at 12:08 PM, Enrique Arizón Benito
<[hidden email]> wrote:
> 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


I think this critique only applies to type systems where NULL is a
special value of each type, and in C-like languages using as a pointer
(or reference) can crash the whole program.  calling a design flaw "a
bug" is just sensationalism.

In Lua (and several other dynamic type languages) nil is a separate,
single valued type, you don't have "NULL pointers", not even "NULL
tables" or "NULL numbers"  just that as usual you can get values of
any type at any point.  Not having nil wouldn't avoid you to get a
number when you'd like a table, or viceversa.  you'd still have to
check for boundary cases.

--
Javier


Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Enrique Arizón Benito
In reply to this post by Udo Schroeter
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 <[hidden email]> 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 <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Enrique Arizón Benito
In reply to this post by Steven Degutis
Hi,

as Rob Kendrick indicated, replacing nil and raising an exception is the only possibility. (and it's a good thing to do, since this avoid the program to continue with an un-initialized variable).

Regards,

Enrique


On Fri, Jan 9, 2015 at 6:21 PM, Steven Degutis <[hidden email]> wrote:
What would happen if you accessed a key in a table that it doesn't
contain? Right now it returns nil. What would it do instead if we
removed nil?


Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Dirk Laurie-2
In reply to this post by Enrique Arizón Benito
2015-01-09 22:44 GMT+02:00 Enrique Arizón Benito
<[hidden email]>:

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

"Always".

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

Another "always".

It seems appropriate to read `always` as a synonym for `IMHO`.

It's perfectly possible to design a language that has no `nil`.
Python, for example. It has `none` instead :-)

But given that Lua is a dynamically typed language, the concept
of a value that is so nonexistent that it does not even have a type
is a very useful abstraction.

Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Javier Guerra Giraldez
In reply to this post by Enrique Arizón Benito
On Fri, Jan 9, 2015 at 3:43 PM, Enrique Arizón Benito
<[hidden email]> wrote:
> Actually the opposite applies. C language handle *REAL* memory directly.

opposite of what?  (just one example of why top-posting is pointless)

(I know why *(0) means instant kill, and also about MCUs (and big
CPUs!) where that doesn't apply. I cut my teeth on 8bit computers when
they were state-of-the-art)

my main issue is not that "you can't do this to Lua, Lua is perfect as
is!", but that those "NULL is a bug!" rants are only a very personal
point of view, often they just reduce to "i hate error checking"

I think a much better approach is the one taken by Go: embrace the
zero.  it's not a language feature, just that it's idiomatic that
every variable starts by being 0-filled, and you're supposed to accept
a zero-value as a valid 'initial' value.  The "Effective Go" document
states that "The zero-value-is-useful property works transitively",
meaning that object initializers can be trivial if all its elements
are just Zero.

there's still error checking, but usually the error comes on a
separate return value, and the error checking code is very regular, so
while not so nice as code that works correctly without checking, is
much more readable than some C code where 2 lines of every 3 are 'just
in case something nasty happens'.

--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Scott Condit
In reply to this post by Enrique Arizón Benito

On 9 Jan 2015, at 20:44, Enrique Arizón Benito <[hidden email]> wrote:

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.

No reason why you can’t experiment as you see fit, but this would depart from what makes a dynamically typed scripting language useful (i.e. parsimonious and flexible) for me.

You can certainly remove the notion of a generic nil to mitigate typing errors, but in a lot of real world (note not “all") cases you may end up replacing nil with explicit type-specific sentinel values or option types that have similar semantics. For example replacing
nullable_list ::= nil | list_element list
with
list ::= empty_list | list_element list
does that. We will no longer confuse an empty list with a variable of another type which is inadvertently set to nil.

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. 
However even an option type or sentinel still gives as a “variable that can not even be read” except by understanding that it represents an empty list but it is not more complex than enforcing nullability by strict normalisation of active variables by scope (which is what I presume you mean by “not possible to have nil errors”, and is easier for program analysis.

But we’ve left behind dynamic typing or implemented a static typing system on top of a dynamic typing system at this point, or required that we normalise code blocks depending on what non-nullable variables they require, which again for my use cases (note not necessarily yours) would make things quite verbose.

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.
I couldn’t really disagree more with this - in the most general case of an array.indexof method, for example, not found can be (note not "always is") an expected result not an exception case, and a generic library probably has some form of that call which indicates this case with an explicit option type, or a success/failure return which has the same effect as an option type, or by a sentinel value (representing a non-reference) which requires comparison specific to the type (and possibly the container instance). You will still have errors if you don’t handle those correctly, and if you do use exceptions, you are simply allowing the error to propagate to a potentially unrelated part of the program but at runtime (note not necessarily in your test cases).There may be a particular implementation for which “not found” violates an assertion which should be true and of course an exception may be suitable then.

You should also look more closely at languages like C - the “null pointer” constant need not translate to a literal pointer value of 0 even if it often does. It’s not really helpful to compare an abstract description of one language geared towards certain things with mere facts about implementations of other languages that are decidedly targeted at different problems.

Scott

Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Peter Hickman-3
There is a language called Icon that returns the success of an operation along with any return value. This would allow searching for an element in a list that is not there to fail (and return no value) or to succeed (and return a value). You your flow of control is based around the success of an operation rather than the value it returns. I'm not sure that the language even had nulls (or anything of that sort) but even if it did have you did not need to reference them in any way.

It was a very nice language.
Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Hao Wu
In reply to this post by Enrique Arizón Benito
the immediate reaction from my head is how you would approach this?

local foo
local bar = function() foo = 1 end
bar()
print(foo)


On Fri, Jan 9, 2015 at 9:08 AM, Enrique Arizón Benito
<[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Rena
In reply to this post by Enrique Arizón Benito
On Fri, Jan 9, 2015 at 12:08 PM, Enrique Arizón Benito
<[hidden email]> wrote:
> 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.

First off, I'm really glad you phrased this in a way that implies "I'm
doing this as a learning experiment and Lua seemed like an ideal
platform for it" rather than yet another "I think Lua should be
changed" message that this list has so many of.

However it seems like your proposal is flawed:

> 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.
You can already trap references to undeclared variables using
metatables. You could modify the compiler to require that variables be
initialized when they're declared, but that wouldn't relate to
removing nil. (Indeed, you could still do "local x = nil".) Anyway,
that's more enforcing a pattern; nothing would prevent bad programmers
from initializing things poorly instead of just not at all.

> 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).
I don't really follow you here. Already, in Lua, values have types,
and variables are references to values. (For "basic" types such as
number and boolean, you can think of it as each variable being a
reference to its own, private copy of the value.) It sounds like maybe
you're proposing the addition of constants, but again, that doesn't
have anything to do with removing nil. (And again, with metatables you
can enforce not being able to modify certain variables, but this does
come with considerably more overhead than "true" constants would
likely have.)

> 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)
Again, I'm not following how no nils = static typing.

> - Simpler and faster code, since there is no need to repeatedly check if a
> variable is nil.
This is a matter of good programming, not one of language design. Why
are you checking if a variable is nil? Presumably that indicates some
condition, as in your next point:

>
> - 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 problem here is that every list implementation will need its own
"end of list" marker. This is a nightmare for interoperability. Now
you need to check for my_list.end_of_list in some places,
some_other_lib.end_of_list in others, etc... it'd be much simpler if
there were a single, standard value that were suitable for use as an
"end of list" or "nothing" marker... which is exactly what nil is.

I think the whole "nil/null is a design flaw" idea comes more from
low-level languages, where everything technically is an integer, and
there are no integers that are universally suitable as a "no value"
indicator (since zero is still a valid value for many variables). This
is already solved somewhat by more modern optimizing/analyzing
compilers (as well as runtime analysis tools such as Valgrind) that
can trace a value's path through the code and detect cases where a
variable might be used without being initialized or a null value might
slip in unexpectedly. Of course this is much harder with dynamic
languages such as Lua, and modern compilers still don't do as much as
they theoretically could to detect potential errors (mostly due to
limitations of the languages), but they do a great job of trapping
some types of bugs.


--
Sent from my Game Boy.

Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Eike Decker
In reply to this post by Hao Wu
If nil was not present, some points come to my mind that would need some special care:
- Function arguments need default arguments as the caller might not even know what's called.
- A function may return any number of values, including none. Assigning results from calls will need a creative solution to work this out
- Any table access would need to declare what type or default value is expected as a table contains an infinite amount of nils right now
- Error indication is currently done through returning nil,"error message". This would need some different treatment if you really intend to check variable types, since this is a primary example where return value types are not expected to be the same for every call.

I think that the later 2 points might be tackled with one solution, however it should respect the multiple-value assignment operation in Lua. Something like 
x,y,z = foo(1,2,3)
needs some kind of indication what x,y,z should become if foo is not returning three values. A simple solution could be to introduce a "no-value" special value, but let's be honest, that'd be just nil with another name :). I think something more like 
x,y,z = foo(1,2,3) as 0,0,0
would be closer to what would be expected. Not specifying default values for return values would result in an runtime error if that function wouldn't return the expected amount of arguments. 
Declaring functions could use the same idiom, like
function foo (x as 0, y as 0, z as 0)



I think it might be interesting to follow this just for fun (if you have the time). There might be some interesting lessons in it. I believe however that yesterdays problems(tm) will be just traded with tomorrow problems(tm) ;) 
Tackling absent values in Lua isn't such a big deal as in C where it can have quite "interesting" effects, beginning with the fact that pointer arithmetics aren't available in Lua...

Besides all that, I once read that NULL is not necesarily a 0 value - it might be anything else, see for example here: http://stackoverflow.com/questions/9894013/is-null-always-zero-in-c

Cheers,
Eike

2015-01-09 23:03 GMT+01:00 Hao Wu <[hidden email]>:
the immediate reaction from my head is how you would approach this?

local foo
local bar = function() foo = 1 end
bar()
print(foo)


On Fri, Jan 9, 2015 at 9:08 AM, Enrique Arizón Benito
<[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Erik Hougaard
In reply to this post by Enrique Arizón Benito
On 09-01-2015 09:08, Enrique Arizón Benito wrote:
the invention of null (nil) references

"nil" is not null. I think you're trying to solve the right problem in the wrong place.

To quote the manual: "Nil is the type of the value nil, whose main property is to be different from any other value; it usually represents the absence of a useful value."

/Erik
Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Kevin Clancy
If that's the definition of nil, then what is the definition of null? They seem like the same thing to me.

On Fri, Jan 9, 2015 at 5:43 PM, Erik Hougaard <[hidden email]> wrote:
On 09-01-2015 09:08, Enrique Arizón Benito wrote:
the invention of null (nil) references

"nil" is not null. I think you're trying to solve the right problem in the wrong place.

To quote the manual: "Nil is the type of the value nil, whose main property is to be different from any other value; it usually represents the absence of a useful value."

/Erik

Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Andrew Starks


On Friday, January 9, 2015, Kevin Clancy <[hidden email]> wrote:
If that's the definition of nil, then what is the definition of null? They seem like the same thing to me.

On Fri, Jan 9, 2015 at 5:43 PM, Erik Hougaard <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;erik@hougaard.com&#39;);" target="_blank">erik@...> wrote:
On 09-01-2015 09:08, Enrique Arizón Benito wrote:
the invention of null (nil) references

"nil" is not null. I think you're trying to solve the right problem in the wrong place.

To quote the manual: "Nil is the type of the value nil, whose main property is to be different from any other value; it usually represents the absence of a useful value."

/Erik


nil is just a sentinel value, except it behaves as false in Boolean expressions. 

It has no further implied significance, even though it is used as the default return value for the __index handler of tables with no meta method defined. 

12