Re: Odd behaviour with multiple return values and varargs

["Kristofer Karlsson" <kristofer.karlsson@...>]

One of the reasons for lua behaving the way it does is implementation.
Returning multiple values just places them on the top of the stack,
and since all function calls need to occur from a fixed stack index
relative to its stack frame, it's impossible to implement the
behaviour that some people would prefer.
You could hack the lua vm and compiler and add more complicated
opcodes, but I guess the developers didnt think it was worth it.

Also, there is of course the matter of predictability, like David
points out (and which I agree with).

In my opinion, if you want this kind of return value list behaviour,
I'd prefer it if you could specify how many parameters you expect from
that function.
Example: local x, y, t1, t2 = trunc(2, getPoint()), trunc(2, getTimes())

Of course, you might want some other syntactic element than my trunc-example.

This would be a less dramatic change to the lua vm and It doesn't
change any behaviour of existing code. I think mostly the compiler
would need to be updated actually.

2007/9/13, David Kastrup <dak@gnu.org>:
> "Tom Miles" <Tom@creative-assembly.co.uk> writes:
>
> > I'm not sure I understand your point.  In my mind, if I have two
> > functions returning 2 values, then I have 4 values plain and simple.  It
> > would be treated exactly the same as print(1,2,3,4).  Is there a reason
> > not to do it that way?
>
> [...]
>
> > As I said before, there is obviously a good reason for the way it is,
> > greater minds than mine have formulated the language, but I don't think
> > you have provided me with a convincing argument.  Thanks for the
> > feedback though.
>
> If I write
>
> a,i = f(a),i+1
>
> then I want i to get the value i+1 regardless whether f(a) feels like
> returning two values or not.  And the same reliable 1:1 relationship
> should hold when I use comma-separated argument lists.
>
> Mapping a tail to a tail is still very much predictable.  But a
> clearly expressed 1:1 relationship between explicit function arguments
> and/or list elements should not be messed with.
>
> --
> David Kastrup
>
>