# A Lua puzzle

A conversation with Marc Bradshaw about a Lua puzzle I found myself in.

``````Lua 5.2.1  Copyright (C) 1994-2012 Lua.org, PUC-Rio
> function x() return 'a','b','c' end
> print(x())
a b c
> print(x(),'d')
a d
``````

A variant of this (`table.unpack` shenanigans) screwed me for about half an hour this morning. I’m sure there’s a logical explanation, but I’m not seeing it.

Could the second print be prototyping as a 2 element list and then dumping the second and third elements of the first argument?

I wondered that, though Lua doesn’t have any concept of prototypes as such. But if that’s the case, why does the first work?

Its not just `print()` though - where this actually bit me was doing the equivalent of: `t = { x(), 'd' }`. This exhibits the same behaviour - `{ x() }` expands to `{ 'a', 'b', 'c' }` whereas `{ x(), 'd' }` expands to `{ 'a', 'd' }`.

What happens if you have a function `y()` which returns `'d'` instead of using the literal?

Interesting thought, and interesting results:

``````Lua 5.2.1  Copyright (C) 1994-2012 Lua.org, PUC-Rio
> function x () return 'a','b','c' end
> function y () return 'd' end
> print(x(),y())
a d
``````

But then:

``````> function y () return 'd','e','f' end
> print(x(),y())
a d e f
> print(x(),y(),x())
a d a b c
``````

So it takes the first value from each of the expanded arguments except for the last one, where it takes them all.

Interesting….

Could it be an optimisation side-effect?

Turns out its documented: http://www.lua.org/manual/5.2/manual.html#3.4

The why isn’t exactly clear. The only possible answer I’ve found is that allowing it would make the following unclear:

``````a,b,c = f(), g()
``````

in that you don’t know whether the values you got back came from `f()` or `g()`. I can work around this with:

``````a = f()
b,c = g()
``````

This looks like an interesting library to work around it: http://luarocks.org/repositories/rocks/#vararg

But of course I could have written something similar in C myself. That’s not quite the point.