I
agree that operating at runtime (RT) rather than compile-time (CT) is
often simpler, that it translates into better maintainability, and that
it is an excellent reason to prefer RT when applicable. If I understood
correctly, you consider adding/changing some syntactical features in
Lua, so that many desirable syntax extensions become doable at RT
rather than CT.
However, I can't see how RT syntax tweaks would
lead to less divergences and incompatibilities than CT ones. Quite the
opposite, when CT and RT stages are clearly separated, and syntax
control exclusively belongs to CT, there is a red line to cross
purposefully before committing syntax rape; you have to be aware of
what you're doing, and you have a last chance to ponder whether it's
worth it. Not so with "fluid APIs": the frontier between regular
functions and syntax hacking becomes dangerously blurry, and you might
cross it without even noticing.
One of the biggest problems with
extensible syntax is composition: you want several, independently
designed extensions to work well together in your source files, just as
for regular libraries. This issue is far from being solved, and that's
why you want to avoid tying a library with syntax extensions: you'd
lose a lot of your library's modularity, which is what the very concept
of library is all about.
I'm not sure that RT syntax tweaks
would be easier to get right than CT Meta-Programming within a
correctly designed framework. Moreover, CTMP leaves the door open to
static analysis, so you can be warned about dangerous and/or
incompatible extensions sooner in the development process. Similarly,
with CTMP, an incorrect syntax is normally spotted at CT, and a
thorough analysis can be done to explain the error clearly; I'd guess
that erroneous uses of RT syntax extensions could be awfully trickier
to fix. RTMP doesn't seem easier than CTMP *for syntax extensions
of comparable elegance and robustness*. A lot of metaprogramming
complexity seems intrinsic, not accidental, and I'm afraid that RTMP
merely shifts part of the burden from the extension author to the
users. Lowering the barrier to entry into meta-programming doesn't look
like a great idea IMO.
About
Ruby: I'm definitely not obsessed with performances and benchmarks and
whatnot, especially in a language that integrates so tightly with C as
Lua, but Ruby is known for its embarrassingly bad performances. That
might be somehow linked to its extreme dynamism (the same could be
written about Io). Lua would be useless for many of its users, if its
performances were on par with Ruby's.
That's it with
generalities :) Now about your proposals: most users agree that Lua
deserves a less cumbersome syntax for closures. After some experience
with Metalua's terser (and Ruby-like!) alternative syntax, I'd say that
in addition to lightweight closure syntax, you want to get rid of the
_expression_/statement distinction. Your proposal to hack "do", with an
interpretation that depends on line breaks, doesn't feel very lua-ish,
but as shown about twice a month in the list's traditional Syntax
Extension Proposal Troll, syntax is surprisingly hard to get right.
Dynamic
scoping usually produces subtle bugs, and is a terrible pain in the
couple of old languages that inherited it: I don't thing it woud cause
less havoc than a clearly separated CTMP stage. Maybe a static operator
inspired by Pascal's "with" could do the job in a slightly cleaner way,
but that construct is quite infamous, in Pascal, as a wart that leadto
subtle bugs. My biased preference goes to a clear, explicit, readable
definition of how those implicit parameters (the current class/instance
in your examples) are handled, and a clear segregation of CTMP code
from RT code. RTMP is friendlier to quick & dirty hacks, but you
probably don't want dirty hacks in your language's semantics.
Your
example with TextFilters is quite interesting. Unless I missed
something, it boils down to "Monads are awesome, let's make them
readable in our language". It's been done in Haskell, and the result is
amazingly powerful indeed, although not intuitive to newcomers.
Definitely, having a nice way to define and use monads in Lua would be,
at least, an interesting experiment. It might fail, however, due to the
lack of static type-checking: many monads are intrinsically tricky, and
are usable in Haskell mainly thanks to the type checker which catches
so many mistakes. I'm fairly confident that monad transformers would be
just unusable without static type inferrence.
CTMP is not necessarily about monkey-patching an unstructured
stream of source code: if it offers the right level of abstraction to
its users, proper error detection mechanisms, and idioms that help
structuring one's code in a readable maintainable way, it's actually
cleaner and safer than RTMP. It generates a lot of noisy discussions
about gratuitous superficial syntax tweaks, as predicted by the
bikeshed theorem (
http://bikeshed.com), but that's a tiny part of what
it's all about. MP is intrinsically hard; something that disguises it
as simple is cheating on you, and will bite you when you least expect
it.
Finally, if you really want to figure out how Lua could
benefit from a more RTMP-friendly syntax, my 2c advice is: put on your
robe and your hacker's hat, get metalua, and try your ideas! :)
