I will try to elaborate on what I meant in my previous statement.
The concept I am referring to is the absence of a value, I'm not using concept to talk about something discussed in the manual or defined by lua necessarily. Just an abstract idea.
I did not intend the phrase "intangible second class value" to be read as hyperbole, perhaps I owe an explanation to my wording.
Let's look at a very simple function declaration:
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.
It is not good enough just to say that missing arguments are nil.
I do agree with you here, I was simply suggesting that removing this "missing", such that we couldn't use a roundabout method to check, would be more in line with lua's design as a whole.
I would be in favour of a value in lua to distinguish the two cases and not actually removing it though. Either way a proper mechanism or none at all is what I think is needed.
Lua's concept of a thing with no value is nil.
This "missing" idea is not a thing with no value. It is not the absence of value. It is the absence of a thing in its entirety, which -- if interpreted as a thing -- has no value.
As such, select('#') is not a hackish workaround but in fact the CORRECT, clean way of doing this. In your example x is in fact nil. There is no concept by which x is not nil. x is a thing, and it has no value. There isn't anything "missing". Rather, argument lists are a separate concept. An argument list is a thing. It is a thing that has a defined value. That defined value is a list with a specific length. That length is, in your example, zero. The difference between f() and f(nil) is not in the value of x, but in the length of the argument list.
> Op Do. 7 Mrt. 2019 om 09:36 het Magicks M <[hidden email]> geskryf:
>> I'm not sure an intangible second class value to represent a concept is the lua way either.
> The phrase "intangible second class value" deserves a compliment. It
> misleads the reader by taking for granterd that 'none' is a concept,
> represented by some kind of value. Actually T_NONE is just a name for
> an integer constant in C. There is no concept 'none', let alone a
> value of whatever class to rpresent it. It might as well have been
> called "missing" or "absent".
> Read the manual carefully. Carefully. Every bit of it. In particular, this part:
> [-0, +0, –]
> int lua_type (lua_State *L, int index);
> Returns the type of the value in the given valid index, or LUA_TNONE
> for a non-valid (but acceptable) index. The types returned by lua_type
> are coded by the following constants defined in lua.h: LUA_TNIL (0),
> LUA_TNUMBER, LUA_TBOOLEAN, LUA_TSTRING, LUA_TTABLE, LUA_TFUNCTION,
> LUA_TUSERDATA, LUA_TTHREAD, and LUA_TLIGHTUSERDATA.
>> The only reason it exists is due to the way the C API retreives arguments from the stack.
> This statement is so vague that it is not even wrong.
> T_NONE exists because Lua calls are allowed to provide any number of
> arguments, and it is not a priori an error to provide fewer values
> tnan the function woukl have been able to use.
> It is not good enough just to say that missing arguments are nil. For
> example, the library function table.insert, since
> table.insert(tbl,key,nil) and table.insert(tbl,item) do different
> things. You really need to know whether that third argument is
> actually present.
Wouldn't this be solved by having table.insert(tbl,item,key) instead?
After all, nil keys are generally considered invalid (and handling them
with metamethods is a little funky and can't be used with pairs()).
It is not good enough just to say that missing arguments are nil. For example, the library function table.insert, since table.insert(tbl,key,nil) and table.insert(tbl,item) do different things. You really need to know whether that third argument is actually present.
This function has always been a gentle eye-brow raiser for me to be honest. This whole “nil vs bounds” issue is one area where Lua isn’t as clean as it could be (imho of course). We see it with the perennial issues with table sequences, capturing arguments into tables, enumerating arguments that might be nil etc etc.
While the OP might be pushing things a bit hard, I think he does have a point. LUA_TNONE *is* a slightly odd way to indicate that you are “off the end” of the stack.
As I’ve said before (though Roberto disagreed), “nil” in Lua is subtly overloaded to mean both “no value” and “not present”. In many cases this doesnt make a practical difference, but when it DOES, it can be confusing since the lack of distinction in most cases lulls new users into thinking there IS no difference; witness all the arguments about sequence.
> While the OP might be pushing things a bit hard, I think he does have a point. LUA_TNONE *is* a slightly odd way to indicate that you are “off the end” of the stack.
It's in principle no different that the time-honoured Fortran trick of
returning -1, -2 etc for errors in a function that should return a
positive integer, or from Unix retund codes of processes.
> As I’ve said before (though Roberto disagreed), “nil” in Lua is subtly overloaded to mean both “no value” and “not present”. In many cases this doesnt make a practical difference, but when it DOES, it can be confusing since the lack of distinction in most cases lulls new users into thinking there IS no difference; witness all the arguments about sequence.
I've never been impressed by arguments involving alleged pontes
asinorum for new users, Nobody stays a new user for long. Sure, the
difference is subtle, but once grasped , never lost.