[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Unexpected error using tostring
- From: Andrew Starks <andrew@...>
- Date: Thu, 7 Mar 2019 17:05:36 +0000
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