Re: Empty? No. Array? No. Has? Yes.

[Andrew Starks <andrew.starks@...>]

On Sunday, July 7, 2013, Dirk Laurie  wrote:
> 2013/7/7 Andrew Starks <andrew.starks@trms.com>:
>
>
>    Tim thinks:
>    -  the need for such a value is sufficiently common and uniform to
>       justify adding a name and value to the Lua language itself;
>    -  using one of the well-known idioms to create a unique value for
>       a particular Lua instance is an inadequate workaround.
>
>    Dirk thinks:
>    -  the reason why one needs it is application-specific (SQL NULL,
>       reserved-but-unused, etc);
>    -  reserving a name by consensus among people that need it is good
>       enough.
>
> You're welcome to add an "Andrew thinks" entry to this list.

Thanks man! I will...

Andrew thinks that:

nil makes a fantastic "empty" sentinel value and a pretty spotty (inconsistent) "delete" verb. The dual role equates to an abstraction and abstractions at the language level are where the flavor and power of the language resides. It is also where conflicts happen, especially if you know that they are there and wish that they weren't, even if only sometimes. 

As a delete verb, nil sets a variable name to itself, which means its not set to what it was set to before. This gets the job done by side effect, quite nicely, but is fundamentally different than deleting something.

This is always true, except when setting a non-existent field name to nil, in which case the field name is left unassigned. If he field name existed and then was set to nil, the normal behavior applies. This is, as you said, true only by coincidence, but it's still true. 

As empty: nil is *assigned* to a variable name, making that variable name very important and busy: cock-blocking access to the same name, further up the stack. Without delete, there are some un-doable, very useful and really important things to understand about your "variable that is now part of your program and does exist and is set to nil."

[Since adding `delete` is comic gold (not sure why, but it was well written so I'm assuming I'm treading on thin ice (wrong)), I'll stay away from that...]

Leaving much of nil's role "implementation specific" leaves some things out of reach, specifically when you would otherwise want to tell the VM, "Be cool baby, I got this shit."

So, defining a few edges of some of the facilities that use nil (or frustratingly (in my view) insist on always returning it :) ) would be a viable way to:

1: Not change 99.999 percent of the language's behavior. 

2: Further emphasize and increase the usefulness of nil's role as "empty," for which it is a natural fit. 

-- Andrew