Looks like Red’s `parse` is just that… a parser. The pattern matching + “shrubbery” notation (see paper; tldr: syntax trees but flatter and more flexible via de

Looks like Red’s `parse` is just that… a parser. The pattern matching + “shrubbery” notation (see paper; tldr: syntax trees but flatter and more flexible via delayed parsing) are waaaay more general as they allow you to define totally new language grammars inside Rhombus itself. Building Red’s `parse` would be trivial in Rhombus. Moreover, compile-time macros fill a different role than run-time extensibility: macros can do some ahead-of-time static analysis and the compiler can emit much faster code with no runtime cost. All I’m trying to say is, if you think Red is more impressive than Rhombus, then you are missing something. :) Rhombus is strictly more expressive than Red. Red might have some nice affordances, but there’s no reason why Rhombus couldn’t have them too. (And I remember speaking with Matthew Flatt about an eDSL someone was building with the macro system—it was embedded regexes that could communicate with the host language about some of their internal structure; eg report number of capture groups for binding information or something like that. Again, this is all done in user-land, rather than part of the “core” of the language.)