 |
lua-l archive |
|
|
||
|
On Jul 4, 2014 2:02 PM, "Carlos Pita" <carlosjosepita@gmail.com> wrote:
>
> PS: at the risk of not getting precise answers for my more technical
> questions, I would like to hear your opinions about the need of
> metaprogramming in lua. As scheme, lua provides powerful basic
> mechanisms that lend themselves to implement new control structures,
> programming paradigms, etc. This often implies boilerplate code that
> cannot always be abstracted out into reusable functions (maybe because
> the function calling syntax isn't ideal for the specific construct,
> maybe because the function calling semantics is inadequate).
Lua is militant that compile aka loadstring(s) is a pure function of the value s. This by itself is enough to eliminate most uses of macros, as you can't import them.
Many of the things you'd do in macros have relatively tasteful Lua syntax. For example, not only is [[ struct "t" ]] available,
struct "t" {
int "a",
float "b"
}
is as well. The cost is that the domain syntax cannot be checked at compile-time, it must be interpreted (at least once) at run-time, any diagnostic messages will be weird, and you often end up having a cons-y interface. Plus poor interaction with lexicals, but that's a pet issue.
The only way to delay evaluation of an argument is to pass it as a thunk. Because function()end is kinda bulky, people seem avoid it.
Jay
[my pet issues: prompt diagnosis of invalid UTF-8, and errorism in general; making it easier to use parsed structures than string concatenation (which means lexical references in freeform syntax); least-intrusive syntax for domain-specific control flow.]