lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

2014-07-15 1:09 GMT+08:00 Jerome Vuarand <>:
> 2014-07-14 16:24 GMT+01:00 Xavier Wang <>:
>> 2014-07-14 22:54 GMT+08:00 Roberto Ierusalimschy <>:
>>>> 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($(
>> 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.

Yes, that may be a good solution, Thank you!

and mapping file or a custom message handler is also very good :)

so the question is turned to, how to get the line-number/column-number
information from error message?

Xavier Wang.