I think that the ease of adding this syntactic change is really irrelevant to whether it should be included. I personally think that it leads to unclear and cryptic code. Also it is not consistent, the same syntax means different things in in different places. Which is a Bad Thing.
From: "Sven Olsen" <sven2718@gmail.com>
To: "Lua mailing list" <lua-l@lists.lua.org>
Sent: Friday, 16 November, 2012 3:36:25 AM
Subject: parser hacking: stringification
Hi guys,
This is another post reporting on a parser hack I've been playing around with. I've been trying to keep my Lua hacking to a sensible minimum; at this point, the only piece of non-standard sugar I'm really attached to is Peter Shook's 'in' shorthand. Peter's is one of the few language tweaks that really does seem to succeed in simplifying a lot of my code without also obfuscating it.
That said, sometimes I can't resist the urge to try making little improvements, and one of the hacks I've been playing with is starting to feel like it may be worth a list post, so here we go:
In my own scripts, I often find that I need to create tables that copy some selection of variables out of the current scope. For example:
{
star=star,
planet=planet,
year=year,
}
To make those tables a bit less verbose and typo prone, I added an extension to the syntax sugar for fields, one which makes
{ ..star, ..planet, ..year}
shorthand for
{star=star, planet=planet, year=year}
I'm not sure what to call this type of shorthand -- and I'm having a hard time thinking of a similar feature in any other languages. The operator it most reminds me of is the "stringification" allowed in C's preprocessor. But perhaps some of the more knowledgeable members of the list can suggest a better analogy :)
Anyhow, once I'd finished hacking the table construction code, I couldn't resist taking it a little further, and adding a version of my "stringification" shorthand to function arguments. The idea here is to simplify function calls like:
draw_point(x,y,"color",color,"size",size,"alpha",alpha)
By allowing them to be abbreviated as:
draw_point(x,y,..color,..size,..alpha)
Both cases of the "stringficiation" shorthand are easy to hack into lparser.c -- together they're around a 50 line diff. My implementation is admittedly crude -- it works by referencing the current token's seminfo string. An interesting side effect of the approach is that the shorthand can sometimes give useful results when it's applied to more complex expressions. For example
{..planet, ..planet.star} becomes shorthand for {planet=planet,star=planet.star} and
draw_point(x,y,..hash[color]) becomes shorthand for draw_point(x,y,"color",hash[color])
I should perhaps throw a syntax error in such cases, but, it's a useful enough feature that I'm tempted to leave the code as it is.
As always, if anyone's interested, I'll take a shot at packaging the diff as a powerpatch.
-Sven
