Re: Idea. Removing nils from the language.

[Hao Wu <wuhao.wise@...>]

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