lua-users home
lua-l archive

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

I find it very frustrating that every time someone suggests an
improvement to the language the response is [...] extending
frameworks that have learning curves way out of proportion to the achievable

Language design is intrinsically hard, it's bound to have an outrageous learning curve, and syntax extensions are a simplified case of language design. There can be two partial fixes to this:
- optimize the whole language for syntax flexibility, i.e. reinvent Lisp yet another time.
- or favor extensions reuse, so that if it's hard, at least it doesn't have to be done more than once.

Making languages successful in the real world is all about the law of
association, about critical mass.

Indeed, there's a risk of balkanization of the language if it supports easy syntax extensions, and it might well be what plagued Lisps as development platforms. The existence of the official Lua definition and implementation by Lualabs is extremely important with this respect: they act as a de facto standardization body, and it demands extreme cautiousness before they add anything to the language.

Successful languages eventually crumble under the support of unfortunate design choices, that have been made too lightly. So the rationalized argument for rejecting most proposals, including the one which sparked this discussion, is: "the gain is marginal at best, whereas touching the standard has huge and unpredictable consequences. Risks are way out of proportion to the achievable gains". So the fact that such tiny proposals are silently ignored by the Lua team is both very reasonable, and completely unrelated to the existence of metaprog systems. These systems don't rob you from the Lua team's attention, they just give you a limited ability to do without it.

Also, the current existence of several metaprog systems, sometimes without a clear purpose beyond the NIH syndrome, certainly doesn't help with balkanization, but that will eventually settle out.

A static meta-programming system offers compromises different from sticking to the plain language:

- it gives up the standard's conservatism. You lose some interoperability, but you get more cutting-edge features. That's the same kind of choice you make when picking a stable or experimental Linux distribution.

- it can still retain a good deal of interoperability, if extensions can be written and used modularly. You can restrict yourself to mature extensions that are worth it, just as you can restrict yourself to good quality 3rd party libraries.

- it gives their chance to syntax experiments. As written above, the sane attitude for the Lua team is to reject virtually all proposals, especially the superficial ones. The only way to prove that your extension is one of the <1% that are worth it is to field-test it on significant code bases, before it is even remotely considered for inclusion in plain Lua. For that, you need something intermediate between inclusion in the official standard, and a shady patch of the original distro. That's what a proper metaprog system provides. Most community-suggested improvements first existed for years as patches, before getting the Lualab blessing.

Static metaprog makes such language changes more flexible. If designed correctly, the system must also make them more robust, let them compose better, and still carry a (more relaxed) sense of standardness.

Another word about the learning curve: the choice is between optimizing it for "hello world grade tweaks" and offering the tools it takes to build a useful and robust extension. It doesn't matter that metalua isn't optimized for writing non-composing, superficial, close variations as the set syntax proposal: first I think they shouldn't be written at all, but anyways, if you really want that sort of thing, the "proper" quick&dirty approach is to patch lparser.c for your project.

As an analogy, most C++ developers can't write proper template classes, but it doesn't really matter: you want them to be able to use STL, not to rewrite it. By exposing the real tool set rather than an interface for dummies, it naturally encourages code reuse. Ditto for other non-trivial metaprog systems.

Bottom line is: I agree with you, static metaprog is an overkill for such trivial hacks, and is no substitute for an integration in the standard. That's partly because such trivial hacks should probably not be written, and certainly not make it to the standard in the first place (if they don't create ambiguities today, they might in the future prevent the addition of much more useful features, by conflicting with them syntactically).

And of course you could strip all the syntax sugar out of Lua, but then it
would be a very inexpressive and limited language of interest only to

It would only make sense if static metaprog made it to Lua's core, which would be silly indeed.