Red: A programming language inspired by REBOL (github.com)

Rust's `macro_rules!` macros operate on ASTs, so the `x` inside a macro definition is different to the `x` in the scope where the macro is used, even though the textual representation of the identifier the macro inserts into the place it's used might be identical. This means that:

  macro_rules! add_two {
      ($i: ident) => {
          let x = 2;
          $i += x;
      }
  }

  fn main() {
      let mut x = 5;
      add_two!(x);
      println!("{}", x);
  }

  fn main() {
      let mut x = 5;
      let x = 2;
      x += x;
      println!("{}", x);
  }

Scripting languages are much closer to Lisp than to C (e.g. compare Python to Racket).

IIRC Ruby, Javascript and Smalltalk (the latter inspiring a lot of OOP languages) were all explicitly designed to be like Lisp.

It should give you place to get started. The cliff node what I did is the I wrote a function that replaces things in a list of lists/a tree and used that rewrite the definition of the function to make it more readable. While it is an toy example I hope it helps.

It's funny to me what a tough sell it is, but that's true for all new dev tools. While the main purpose is to help anyone, whatever grammar they choose (ABNF, EBNF, etc.), it all compiles down to Red `parse` internally, so if you use Red, your parser is already done. If you use the native `parse` rules to begin with, you can even include actions. Testing in it is cool too. But really it's to try and get people to see that documenting your design (meaning you have a design to begin with), is valuable.

Let's see. Java? Python? Ruby? JS? PHP? Any .NET lang?

Go is on the rise, yes. As is Rust. But D? Nim? Do you really consider those major languages?

Enough silly arguments though. We think it's special to offer options, because one size does not fit all, but we hope a common syntax can fit most. So you have the option to 1) use an external runtime, which makes all your EXEs tiny (say they run in a common system, even against a custom Red runtime you build); 2) compile to native code and get a single, no dependencies, EXE; 3) "encap" your code with the compiled runtime so you can leverage all dynamic features of Red, some of which can't be compiled; 4) compile the runtime so it can be accessed from other languages and environments. 5) Write in pure Red/System, which is basically like writing in C. Maximum control, no high level features. Tiny EXEs, no runtime, fast compilation.

- https://www.red-lang.org/2017/03/062-libred-and-macros.html (please note the Excel+Red Pong demo)