Re: Propsoal: a lua dialect without nil

[Jim Whitehead II <jnwhiteh@...>]

On Tue, Feb 15, 2011 at 10:46 AM, Steve Litt <slitt@troubleshooters.com> wrote:
> On Tuesday 15 February 2011 05:20:43 Axel Kittenberger wrote:
>>   In the 5th century BC Hippasus is said to have been killed by
>> Pythagoras, because he insisted on the fact that rational numbers do
>> not cover everything like sqrt(2). This is an urban lebend, sometimes
>> used as reference to hope to not get the same kind of response as 2500
>> years ago when suggesting something against the "doctrine". I won't
>> discuss irrational numbers but the virtue of letting go of nil. You do
>> not have to be convinced nor do I expect Luiz and Roberto to change
>> Lua. If it can be managed to be patched to the lua core it will be a
>> dialect. For now its just an idea I'd rather have written down once,
>> than letting it go to the drain immediatly.
>
> Just speaking for myself, I like nil just the way it is. It's easy to deal
> with, it makes sense in a "you know what I mean" sort of way, and makes things
> easy. I sure prefer nil to the syntactic edifice you'd have to erect to
> replace it.

Although perhaps not the best model for comparison, the Go programming
language has to deal with uninitialised value, including pointers. The
decision made by the language designers was to introduce a 'zero
value' for every single type, which in the case of reference types
(arrays, slices, maps, structs) is nil.

Although this helps to 'solve' the problem and gets rid of nil other
than the zero value for pointers, you end up with bizarre
constructions like the following for maps:

someMap := make(map[string]string)
val, ok := someMap["foo"]
if ok {
  // The contents of 'val' is the value corresponding to the key "foo"
} else {
  // The contents of 'val' is the zero value for the given type, in
this case the empty string
}

And the same sort of problem occurs with removing a key/value pair
from the table:

someMap["foo"] = "", false

Certainly, you could write some wrappers around this that are
analagous to the table.unset() function you propose.. but I'm not sure
any of this solves a particular problem or are any cleaner than the
alternative, which seems to be what we already have.

Just some thoughts,

- Jim