lua-users home
lua-l archive

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

Mark Hamburg wrote:
The downside to macros is that they can rapidly cause a language to diverge
with a variety of competing syntax changes. Presumably we add macros to get
greater expressivity, so I wondered whether there were big wins available
without introducing all that a macro system can lead to.

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 (, 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! :)

-- Fabien.