lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 



On Thu, Jun 28, 2018 at 8:31 AM, Kenneth Lorber <keni@his.com> wrote:



On Jun 27, 2018, at 9:51 AM, lua-l-request@lists.lua.org wrote:

Date: Wed, 27 Jun 2018 12:06:41 +0000
From: Thijs Schreijer <thijs@thijsschreijer.nl>
Subject: Re: require() parse error in 5.3.4/5.4.0-work2?
To: Lua mailing list <lua-l@lists.lua.org>
Message-ID: <22747BE4-5113-4917-8795-49F0784C7E5F@thijsschreijer.nl>
Content-Type: text/plain; charset="utf-8"




On 27 Jun 2018, at 13:15, Kenneth Lorber <keni@his.com> wrote:
On 26 Jun 2018, at 13:13, Kenneth Lorber <keni@his.com<mailto:keni@his.com>> wrote:
On Jun 23, 2018, at 8:57 AM, Andrew Gierth <andrew@tao11.riddles.org.uk<mailto:andrew@tao11.riddles.org.uk>> wrote: 

[...]
To me it is about flexibility, multiple return values, and the ability to only take what is needed. Eg: 

 take_two(return_three())
Without a bunch of locals. Why would you even want to limit that and make it an error? It takes flexibility away.
For example: take OpenResty, it uses a lot of those extra checks and it's a pita. See this code for example: 

https://github.com/Kong/kong/blob/82a51c4b519728eed4f957fdaa547ed4abea9332/kong/globalpatches.lua#L296-L302
The last argument “socket options” must be a table, not even `nil` is accepted. Hence in the calling code it requires an if-then construct. 

So be careful what you wish for with those checks.

Thijs
I was going to just let this go, but the replies are getting so far afield I just can't. I'm not asking about the language feature in general, or about function prototypes, or user written code or any of the other things people have brought up.
I'm talking about the basic, lua-distribution-supplied functions such as require. So let me rephrase my original questions and we'll just stick to require only:
Is there some reason accepting require("file", "ignored argument") is a language feature? Some use-case I don't see? (If so, why is there the occasional check for extra arguments?)
Is it documented somewhere I missed that lua functions supplied by the distribution accept and ignore extra arguments?
Is there any reason not to add checks for extra arguments to the functions supplied by the lua distribution? If it's performance, it could be available as a compile time option.
I hope this gets the discussion back on track, whether anyone agrees with me or not. 

Thanks,
Keni
The way I see it, Lua tries to be as “unspecific” as possible, as in that the global environment itself is just a table for example, as are all libraries, and the registry, and every global can be redefined by a Lua version.
In your example `require` is just a function, as any other Lua function. With your proposal you’re defining “Lua defined functions” and “language defined functions” as separate types/behaviours. Why this complication? 

Thijs
Since we are clearly not communicating effectively, let's try this from another direction: 
> math.random(3,4,5)
stdin:1: wrong number of arguments

> t={}
> table.insert(t,1,2,3,4)
stdin:1: wrong number of arguments to 'insert'

Are these bugs that should be fixed in Lua?
You bring up the point that some functions in the 'standard' Lua libraries check the number and/or type of parameters while others do not. 

* t = require('table', 1234)   -- second parameter is silently ignored
* n = math.random(1, 10, 100) -- third parameter causes function to throw an error * table.insert(t, 1, 2, 3, 4) -- fourth parameter causes function to throw an error; also if zero or one parameters 

You then ask

* whether there is a reason for this difference
* is it a bug in Lua (the language)
* is it a bug in one or more of the standard Lua library functions (I added this alternative place for a bug) 
* if so, do they need to be fixed
I suspect that the difference in behaviour is due to implementation, with a bit of history and inertia.
'require()' checks that the first parameter is a string (after coertion), but does no other parameter checking. It would take additional code to check for the number of parameters passed in.
'math.random()' have three behaviours depending on whether the caller pass zero, one or two parameters. It throws an error (a fourth behaviour) for any more than two parameters. The function is written in C and uses a switch statement on the number of parameters to decide what to do. It is trivial to provide a 'default' case to throw an error for more than two parameters.
'table.insert()' has two behaviours depending on whether the caller pass two or three parameters. It throws an error (a third behaviour) for zero, one or more than three parameters. The function is written in C and uses a switch statement on the number of parameters to decide what to do. It is trivial to provide a 'default' case to throw an error for the wrong number of parameters.
By design, Lua (the language) does not check that a function call provides the correct number or type of parameter. This allows lots of useful things.
If a function wants to check its parameters, standard Lua operations are available to do so, but each function must do its own checks.
My conclusion is that there is definitely not a bug in Lua (the language).
The next question is whether there is a bug in one or more of the library functions.
* Should 'require()' (and any other function that silently ignores extra parameters) throw an error? * Should 'math.random()' (and any other function that throws an error for extra parameters) silently ignore them? * Should standard library functions be consistent in the way they handle extra parameters? 
* Should someone put in the effort to make it so?
There is no easy answer to these questions. The rest that follows is my opinion.
I would prefer that functions silently accept extra parameters, like Lua (the language).
I would be happy if 'math.random()' silently accepted 3 or more parameters. It would seem to be trivial to implement, with the 'default:' case in the switch doing the same as 'case 3:', but I suspect my quick look at the code has ignored the size of the stack or something.
It is slightly more difficult for table.insert(). The error case would have to be restricted to zero and one parameters. The 'default:' case would do the same as 'case 3:', but, once again, I have probably overlooked something.
In any case, changing the code will mean someone has to spend the time to look at these issues.
Silently accepting extra parameters might make learning the language or the library functions more difficult. It might make debugging problems more difficult. I have not looked at all places where functions throw an error on extra parameters.
It is almost certain that if any of the standard library functions changed to the other 'mode', someone's software would break. It is absolutely certain that somebody's expectations would break, because it would be different from before. Someone will complain.
It is almost certain that someone else will ask the same question about consistency if the standard library functions do not become consistent in the way they handle extra parameters.
It would be nice on some level if there was consistency in the standard library functions; my preference (which, surprisingly, has not changed over a few paragraphs) would be to silently accept extra parameters, the Lua way.
Overall, however, I would prefer that the implementors of Lua and the standard library functions continued working on important language issues, rather than fixing minor inconsistencies in already working code. 

Stephen Irons