Re: Oddity with tinsert (Lua 4.0)

["Jonathan Branam" <sspeare@...>]

> > 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.

tinsert is actually a notable exception. I should have looked at
it specifically before responding. However, many other functions
do not explicitly state what their behavior is, if passed an
incorrect number of parameters.

Actually, almost no functions *describe* their behavior if passed an
incorrect number of parameters. However, all of the functions with
Lua code example implementations implicitly describe what will
happen.

Perhaps the user guide should state, "All functions will ignore any
arguments after the number listed that they take." This is a reasonable
assumption, but not one which is valid unless it is guaranteed.

Personally, I don't write my code this way. I write my functions to
execute on the top of the stack and work downward. This way I can
call many of them from C without having to create a new stack or
empty everything off of it. If you call my functions, in many
cases you can add extra parameters to the beginning without any
effect. But that is just me... Unless it is explicitly stated what
happens when more/less paremeters are passed, it can often be quite
unexpected.

>
> > 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.

Sorry, I really don't use the stdlibs much at all. I see
now that tinsert(a, b) will insert at the end of the table if
passed only 2 parameters.

I think maybe you can see my point, though. Using a slightly
different example, settagmethod takes 3 parameters. If the last
parameters is nil, then it restores the default behavior. So, calling
settagmethod(tag, event) will probably restore the default behavior.
Or maybe it will *error* saying not enough parameters. It is dependant
on the implementation.

My point is that, when you pass more or less parameters to
a function, it is not necessarily defined what will happen.

>
> > 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?

You have a good point here. Every C function is essentially called like a
lua
multi-argument function. What this means is not that C and Lua functions
behave differently, but rather that C functions behave like Lua
multi-argument
functions. C functions and Lua multi-argument functions can be much more
flexible
in their parameter handling than Lua functions which specify their
parameters.

You are correct, the function does not behave identically to the listed lua
code.
However, it does behave properly given only its description. I have never
looked
extensively at tinsert to determine its behavior if I pass too many
parameters to
it. So I did not assume a specific, implementation dependant behavior. My
fault.

Sorry for not checking my references better. You are correct,
tinserts behavior does not match the example Lua implementation.

-Jonathan