Re: Propsoal: a lua dialect without nil

[Francesco Abbate <francesco.bbt@...>]

2011/2/15 Axel Kittenberger <axkibe@gmail.com>:
> Nil is not a first class value. It has a recurring scheme of cases
> where it has a strange kind of double-meaning, nil as variable not
> there, and nil as a result of something not-being there stored in a
> variable, now not there. Same with recent discussions what to do if
> inserting nil into a list. Or people requesting how to differ if a
> function was called without a parameter or with nil as parameter. This
> can be achieved in lua with select('#', ...) and only highlights more
> the funky meaning of nil. This problems might exist more in heads of
> the coders than the language/interpreter, since when learned all the
> details how nil behaves you can work with it. However, even if so, a
> good programming language should be aimed just as much to the heads to
> coders than of cpus - thats all what in my opinion object oriented
> programming was about - to better fit in the way we humans think
> natively. The issue most directly on hand is type-safeness and let
> errors happen where they occur instead of returning nil and error
> later. local condition = some_function(); if conditonn then  --- will
> always silently fail, even if some_function returned true.

In my experience with Lua the usage of 'nil' does not pose any problem
because its meaning is very clear and simple. It is true that in some
cases a nil value can be detected later in the flow and this is
annoying because the error pop up not when the logical problem arise
but only later when the object is inspected. For the other side the
'nil' value is very useful to signal an error or a value not there and
if you ban it you need to adopt more complicated conventions to signal
errors of values that are not present. This complication can make the
code less expressive and concise and is therefore detrimental to the
clarity and elegance.

The option adopted by Python to raise an exception to signal any kind
of problem force you to make more checks before doing operations or to
use try/catch block that are expensive and not so elegant.

So in my experience the 'nil' value in Lua is really well thought and
contribute to its unique, fresh taste.

For me the main problem of Lua is the absence of any kind of type
checking and variable declaration check. This can be really
problematic in complex program where many small error are not detected
at all and they become evident only at runtime potentially quite far
from where the problem is located.

In my opinion it would used to have a dialect of Lua fully compatible
with standard Lua that let you declare the type of the values and
catch any non-declared variable so that you can write:

function roots(a: float, b: float, c: float) : float
  local d = b^2 - 4*a*c -- if I forget 'local' an error will be raised
  return (-b + sqrt(d))/(2*a), (-b - sqrt(d))/(2*a)
end

Note that in this snippet there is a potential error since the sqrt
function is normally in the math module. The standard Lua will not
raise any error until the execution time when it will try to call a
nil value. With the typed Lua a error should be raised to say 'sqrt
variable undeclared' just during the parsing of the code.

In order to be complete the type system should also allow to define
some types for classes. This is more complicated and require some
delicate design choice but I guess it is still possible and can also
bring some advantages.

This kind of programming style could allow to detect much more errors
with a clean syntax and complete Lua compatibility.

Francesco