Very neat. I haven't spent much time with Ruby, but in my estimation it's Lispier than Python and Matz is less actively hostile to such comparisons than GVR. :D
Ruby is much lispier than Python, but it has the same fundamental deficiencies as Javascript (which is even lispier in that the idioms in Javascript are so closure-dependent); it's idiosyncratic, not particularly orthogonal, and nowhere nearly as powerful as Lisp.
Don't take my comment as a recommendation for Ruby. I use it in preference to Python, but Lisp is a better language.
I'm currently looking quite seriously at Julia... it'll be interesting to see if they move it in a more general purpose direction, out of it's current numerical programming niche. What's most interesting is that Julia has Lispy macros in an infix language. I'm not quite sure how they do it, but it seems to me that macros for infix languages was solved in 1973 with CGOL...
The fundamental fact about Lisp macrology is that macros are not parsers, they are semantic expanders. The parser is really the reader, which is very simple and can parse only a few types of things. You can support infix syntax naturally by replacing the reader with a Pratt parser, which adds support for expanding the parse table dynamically as well as for operator precedence. But nobody actually wants to write parsers for every little macro (I think this is a UX issue that other languages based on extensible parsing get wrong). But nobody says the parsers (parser-lets) have to be hand-written. There is nothing stopping you from automatically generating the parser-lets from the macro description itself. The destructuring lambda list for each macro should give you all the information you need to generate a parser-let for most common code shapes you might want to use. From there it's a simple task to turn everything into lists, vectors, what have you.
There have been lots of infix macro implementations, but to my knowledge none of them makes it over the usability hurdle, so they don't get much used. I tried writing one for a very simple infix language (arithmetic expressions, function calls, and little else) and even there it turned out to be too much of a pain to be worth the trouble. The operations needed for generating code were so awkward that they quickly overwhelmed and obscured the code itself, much as how if a product requires packaging that is too unwieldy and expensive, it changes the economics of the product.
Only the Lisp notation seems to be lightweight enough to make full macros easy enough. It isn't just s-exprs; it's also quasiquoting (backquote-comma-splice). Those two together are what keeps the structure of the macro close enough to the structure of the code it's generating. Once you have a notation that is supple and lightweight enough, you begin to think in terms of it — and that leads to qualitative changes in your programming.
But it sounds like you have some neat thoughts on how to overcome the unwieldiness of infix macros. It would be interesting if someone figured out how to make them work well.
p.s. I'd never heard of CGOL (thanks!). Perhaps it invalidates everything I said.
"What's most interesting is that Julia has Lispy macros in an infix language. I'm not quite sure how they do it"
Yeah, Julia-macrology seems to be a funny mixture of operating with infix and prefix representations. You write the macro in infix (in Julia), and the generated output code in infix (or I guess you can generate Expr-type data structures directly), but if you want to inspect the piece of code that was the input to the macro, you need to understand its internal representation as an abstract syntax tree (lisp-like representation), and inspect that.
