SOOO confused about module varargs

[parallax7d]

So the Quickie library has an init module. When I print ... I get the path to the library:

Code: Select all

print(...)
lib.ui

But when I print out the arguments in arg I get 3 different values:

Code: Select all

arg[-2] = '/Applications/love.app/Contents/MacOS/love'
arg[-1] = 'embedded boot.lua'
arg[1] = '[path to love zip file]'

The question: Why are ... and arg different? When I use varargs as a function parameter I can access ... or arg and get the same exact values back. I always assumed they were 2 interfaces into the same data store? Is this a Lua thing or is Love doing something explicit with module varargs?

[slime]

'arg' being a table containing the vararg statement was only a feature of Lua 5.0 and older. Lua 5.1 (released in 2006) changed it to just be '...'. LÖVE uses LuaJIT 2, which is based on Lua 5.1, so 'arg' doesn't contain varargs.

Unfortunately the online version of the Programming in Lua book is the first edition, which was written for Lua 5.0, so it will tell you incorrect things about features that have changed in 5.1.

The standalone Lua interpreter executable, as well as the LÖVE executable, populate a global 'arg' table with the command-line arguments passed to the program.

[parallax7d]

That clarifies things, thanks. By the way, which version is Love using 5.1.4 or 5.1.5? When I print out the version it just says 5.1

[parallax7d]

After some experimentation, it seems like both arg and ... will work in functions with a ... param. But they seem to conflict with each other.

works

Code: Select all

function argTable (...)
  print(arg[1])
end
argTable(3)
> 3

works

Code: Select all

function vararg (...)
  print(...)
end
vararg(3)
> 3

huh?

Code: Select all

function combined (...)
  print(...)
  print(arg[1])
end
combined(3)
> 3
> stdin:3: attempt to index local 'arg' (a nil value)

Since there seems to be support for either syntax, and tables are sometimes nicer to work with than functions - #arg vs. select('#', ...) for example, I'm confused on what to do. Is it the case that Lua only 'half' dropped access to arg, and it should really be considered deprecated and unsafe? Or is it that you should just choose one style or the other? Things are starting to make more sense, but still kinda confused on what would be best practice.

[slime]

LÖVE 0.9.2 uses LuaJIT 2.0.3, which is based on Lua 5.1.x. The changes between Lua 5.1.4 and 5.1.5 were just bugfixes in Lua's own code, but LuaJIT doesn't use Lua's codebase so it's not really based on any specific 5.1.x release of Lua.

Is it the case that Lua only 'half' dropped access to arg, and it should really be considered deprecated and unsafe?

Lua 5.1 can be built with a "5.0 compatibility" mode enabled, which will let you use 'arg' like that even though it's deprecated. LuaJIT (which LÖVE uses) is not built like that, and other builds of Lua 5.1 might not have that backwards-compatibility feature enabled either.

You can easily replicate the behaviour of Lua 5.0's 'arg' by doing this:

Code: Select all

function foo(...)
    local args = {...}
    print(#args)
end

So there's no reason to use 'arg' even when it's available.

[davisdude]

Maybe arg in this case is just an accidental global?