[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Oddity with tinsert (Lua 4.0)
- From: Reuben Thomas <rrt@...>
- Date: Sun, 12 Aug 2001 10:06:33 +0100 (BST)
> I bet there are many other functions which have similar
> behavior. What we would really need is a document
> describing exactly what behavior the standard library
> functions should conform to in cases such as this.
??! We do have such a document: the user guide.
> A similar situation could occur if you passed LESS
> parameters to a function than it expected.
> tinsert(t, 3)
> would probably set the 3rd parameter to nil, which
> isn't exactly obvious.
What???! tinsert(t, 3) adds "3" to the end of the list.
> I wouldn't really call this a bug either.
Of course it is a bug. The function is not working as described in the user
manual. The only argument I can see against this is that perhaps C functions
should not be expected to adjust their arguments in the same way as Lua
functions, but that introduces a subtle and dangerous asymmetry; besides, I
override many of the standard C functions with my own Lua wrappers, so how
am I to know in general whether I'm calling a C or Lua function?
> passing an incorrect number of arguments to a
> function. One could probably argue that it should
> in fact take the last argument instead of the 3rd.
There is no argument. There is a specification in the user manual to which
the implementation does not conform.
> Not that this changes anything, but it 4.1
> I believe you could simply:
> tinsert(t, 3, (gsub(...)) )
Indeed, but this shouldn't be necessary.
http://sc3d.org/rrt/ | free, a. already paid for (Peyton Jones)