lua-users home
lua-l archive

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

On 25 Feb 2008, at 11:01, John Hind wrote:

And I find it very frustrating that every time someone suggests an
improvement to the language the response is loads of elaborate schemes for doing it within the existing language or through patching and extending frameworks that have learning curves way out of proportion to the achievable gains. I would not mind if it *also* got taken seriously as an improvement to the language, and of course 'taking it seriously' includes rejecting it (with reasons). It seems that such suggestions just sit in the archives to
be re-discovered by someone else a few years down the line.

Making languages successful in the real world is all about the law of
association, about critical mass. There's a reason why we're all speaking English here! If you fragment a language into lots of little sub- dialects it
will never achieve that mass and will be overtaken by other, probably
inferior, languages. Of course I could use Lua as a toolkit and make a
language that worked exactly like I wanted, but for a language to be useful,
other people need to speak it too!

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

Fabien recently mentioned on this list how macro extensions to a language do not scale well (my words), in the sense that multiple different tricks may bite each other. Unlike libraries and extension packages, which people can pick and combine as much as they like. See:

You make a very good point IMO. I can only hope that the Lua designers share your view that the language needs to have just the right properties to allow others to build lots of code on top - in such a way that it can be mixed and matched as much as possible.

To drive the point home pedantically, because I think it is absolutely crucial: if one can add a feature oneself without compromising Lua as a modular foundation, then by all means leave it out of the core - but if it leads to even the slightest bit of chaos, please set a standard so library/package creators can build upon that and move on.

I repeat: the core needs to define everything library/package creators need. No more, no less.

In the case of sets, which only aim to simplify notation at the application level, it appears that leaving things as is would be fine. As Fabien said: table.transpose{ "foo", "bar" } will eval to { foo=1, bar=2 } - so there seem to be a couple of easy ways to simplify notation oneself.