3 ms·

Looking through the examples, macros and pattern-matching, for me that would be impressive like 10 years ago. If you want to see really innovative, readable an

Looking through the examples, macros and pattern-matching, for me that would be impressive like 10 years ago. If you want to see really innovative, readable and powerful language check out Red. While the language development seems to be ceased, the ideas (coming from old proprietary Rebol language) of working with code and data go much deeper than just macros: it has built-in DSL (called parse) for making DSLs on the fly and not just pre-runtime code manipulations. https://www.red-lang.org/ https://www.red-lang.org/ And there is XL language which might have even more powerful extensibility features, like adding types or pattern matching or asynchronous processing. Sadly I couldn't compile and try the only implementation it has, only judging by the docs explaining its ideas. https://xlr.sourceforge.io/ https://xlr.sourceforge.io/

ashton314 2y ago
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.)
- mapcars 2y ago
  Parser is one of the show cases of the fundamental language approach to not have "code" and "data" but only have data, which might occasionally be interpreted using different parsers. One example I don't think you can reproduce with macros is something like this (I don't have Red at hand) args: [x y] # these are literal items, like quote in lisps code: [x * y] my_func: func args code print my_func 5 10 # prints 50
bw86 2y ago
> While the language development seems to be ceased Red 0.6.6 was just released: https://www.red-lang.org/2025/03/066-memory-management-improvements.html https://www.red-lang.org/2025/03/066-memory-management-impro...

ashton314 2y ago

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.)

mapcars 2y ago
Parser is one of the show cases of the fundamental language approach to not have "code" and "data" but only have data, which might occasionally be interpreted using different parsers. One example I don't think you can reproduce with macros is something like this (I don't have Red at hand) args: [x y] # these are literal items, like quote in lisps code: [x * y] my_func: func args code print my_func 5 10 # prints 50

bw86 2y ago

> While the language development seems to be ceased Red 0.6.6 was just released: https://www.red-lang.org/2025/03/066-memory-management-improvements.html https://www.red-lang.org/2025/03/066-memory-management-impro...