Re: Idea. Removing nils from the language.

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