Re: Idea. Removing nils from the language.

[Rena <hyperhacker@...>]

On Fri, Jan 9, 2015 at 12:08 PM, Enrique Arizón Benito
<enrique.arizonbenito@gmail.com> 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.