Re: Unexpected error using tostring

[Andrew Starks <andrew@...>]

Responses within....

From: "lua-l-bounces@lists.lua.org" <lua-l-bounces@lists.lua.org> on behalf of Magicks M <m4gicks@gmail.com>

Let's look at a very simple function declaration: 
function f(x) 
   return  x
end

If I call it f()  what is x? The answer is nil, but this is the same when we call f(nil). When we are just considering a pure lua function there is no way to know how f was called. There is no lua value to represent the difference. This to me satifies the definition "unable to be touched; not having physical presence." (intangible). Second class because we have to go through the process of using select with a vararg.
-------

AS: The definition of `function f(x) end` means that there is one value, `x`. Because Lua adjusts the arguments to match the definition, filling in handy `nil` where you failed to provide a value, the value will always be `nil`. There is no ambiguity, unless you define f as `f(...)`, but even here, no ambiguity if you assign the first value of `...` to `x`:

```
function f(...)
    local x = ... --1 value will always be returned, regardless of the value of select('#', ...)
    return x
    -- return (...) -- gives you one value always, too.
end


```
----
> It is not good enough just to say that missing arguments are nil.

-----

AS: It has always been good enough for me, without exception. There are a few times when I was surprised by the way parts of the API worked with nil/one return value/no return value. Once I considered the design or had it explained, it made sense. I've never had anything that was hard to do because of the way Lua treats missing arguments and `nil`.
------------
<snip>

The concept that `nil` is bringing to our attention is Mu: (https://en.wikipedia.org/wiki/Mu_(negative))
Unknown. Neither true or false, just absent. Un. Outside of reason or cause.

I think the reason why this comes up repeatedly is because the concept of `nil` is hard for humans to grasp and probably harder to design into a language. You have to stop at some point and "some point" is never going to be completely satisfying. 

When you try to describe `nil`, it comes into existence and needs to be represented. Representing something that represents the absence of anything results in a difference between modeled intent and reality and so you recursive pattern. Once you bring nothing into representable value, it's Turtles all the way down: https://en.wikipedia.org/wiki/Turtles_all_the_way_down

So, at some non-representation level, you have to be able to express whether the answer to your question was `nil` (how many of them you got), or no answer at all. That can't be a value of any kind, and so something like `select` is reasonable. 

When trying to solve a pragmatic problem while programming in any language, it's easy to critique design choices like this one. How a language handles false and nil have a big impact on its design.

-Andrew