Re: Lua is not skin deep

[David Manura <dm.lua@...>]

Asko Kauppi writes:
> The problem with the error messages is that what the eventual Lua  
> parser sees is not what the user saw.....
> ...[exp]	->	(select(exp,...))
> .....if there's something at runtime, Lua will report the function
> "select" to be involved.

We might restructure it so that the translated parts raise no, or only explicit,
errors.  Alternately, the translated code could inject extra debug information
into the source, somewhat like below.

Original:

  y = (function(x,...) print(x, ...[x]) end
      )(nil,2,3)

Translated:

  _G['ERROR: bad argument to ...[]'] = function(...) return select(...) end
  y = (function(x,...) print(x, _G['ERROR: bad argument to ...[]'](x,...)) end
      )(nil,2,3)

Result:

  $ lua test.lua
  lua: test.lua:1: bad argument #1 to 'select' (number expected, got nil)
  stack traceback:
          [C]: in function 'select'
          test.lua:1: in function 'ERROR: bad argument to ...[]'
          test.lua:2: in function <test.lua:2>
          test.lua:3: in main chunk
          [C]: ?

Lua could support this better, such as with a traceback that recognizes errors
of the form 'ERROR:' and reformats them more meaningfully:

  lua: test.lua:3: 'ERROR: bad argument to ...[]'
  stack traceback:
          test.lua:3: in function <test.lua:2>
          test.lua:4: in main chunk
          [C]: ?

The use of _G is a hack, and some compiler directive for inserting debug info
would be more ideal.  The required function call or closure could be avoided
with support for statements inside expressions[1].

[1] http://lua-users.org/wiki/StatementsInExpressions