Re: #line specifier in Lua

[Jerome Vuarand <jerome.vuarand@...>]

2014-07-14 16:24 GMT+01:00 Xavier Wang <weasley.wx@gmail.com>:
> 2014-07-14 22:54 GMT+08:00 Roberto Ierusalimschy <roberto@inf.puc-rio.br>:
>>> I just hopes to know how Luiz & Roberto think about add a #line (or
>>> other syntax) to Lua, specific the line number of next line, this is
>>> useful when you write a preprocessor (somethings like [1] or [2] or
>>> LuaMacro[3])
>>>
>>> the implement may very easy: when llex read a #line, it set the
>>> lastline (or linenumber?) field of LexState.
>>
>> It is not that easy. A #line directive without a file name is a half
>> baked solution, and to store multiple file names in a chunk would
>> require some new data structures. (Nothing impossible, but it is
>> not trivial.)
>>
>> -- Roberto
>>
>
> But in Lua-spec, pre-processor needn't include file. metalua,
> LuaMacro, luapp all do not support include other file. because in C,
> macros and declares are in the same level with C code, and macros
> operate on string, but in Lua, we don't need declare, and macros is in
> the different level (compiler-time run) of Lua code, that means, we
> needn't include other file to baked source.
>
> if needed, we only require a normal lua file in the compile-time, and
> using macros, some codes like this:
>
> #local foo = require "foo"
> print($(foo.bar()))
>
> in C, #include is just simply insert text into current source file,
> but in Lua, # is eval codes when convert file into baked source, all
> macros lives in different level with code, and not only string but
> full-functional lua objects.
>
> I think with this concept, only liner change statement/sign is enough.

If all you need is macro expansion, you don't need a #line mechanism,
you can simply have your macro output fit into a single line so that
it doesn't modify line numbers if the processed file. And you don't
have to do that manually for every macro, that can be automated: any
piece of Lua code can be converted to a single line with some basic
rules and a few semicolons. But that only works for pointing at where
the macro is called, not where it's defined (so you wouldn't be able
to debug a runtime error in the macro definition itself).

The other common use cases for a #line directive (errors in macro
definition, file inclusion, code generation) definitely require a
filename in addition to the file line to be useful.