A MOS6502 assembler impleme​nted as a Rust macro

Link appears to be broken, working one is:

https://play.rust-lang.org/?gist=a18d697454f9261b28ff

That ... is ... f*ing ... ugly to look at.

This isn't a procedural macro: Procedural macros run Rust code to transform your program, and interact with the guts of the compiler (AST, etc). That's hopefully going to change to not be compiler-version specific, etc.

This is using a system known as "macro_rules" which are a system of "expanding" -- in some ways it's a fancier version of the C preprocessor, but also resembling the Lisp/Racket macro system to some degree too.

Let's take a random little piece of that code from the post and talk about it:

    macro_rules! codelen {
        () => { 0 };
        ( $($c:expr),+ ) => { [$($c),+].len() };
    }

This declares a new macro substitution rule called `codelen`. Without going into too much depth, that's defining rules (on the left hand of the `=>`) and saying what code to expand them into, on the other side. The first replaces `()` with `{0};`, just a simple substitution. In the second rule, the `$($variable),+ is the essential construct here, letting you operate on sequences of input stuff.

It's a little hard to read -- writing your own macros in Rust is a little bit complicated and I don't think it's actually something that should be done often. You can write little DSLs with it for sure. This variety is going to stick around and will keep working. It is called macro_rules! and not just macro! to leave that name free for a future, enhanced way to write macros, though.

  >  Is this a "procedural" macro? 

This is not a procedural macro, it's a regular-old macro.

  > Does Rust specifically target writing DSLs using its macro system?

I would say that "specifically" is a bit strong, but they are one application of them, yes.

  > Can we expect macros like this to continue working for a long time?

This functionality runs on Rust stable, and therefore should continue working forever.

The post you're referring to is talking about procedural macros/syntax extensions/compiler plugins, which are not stable and will see lots of change.

We also may end up with a new macro system as well, but it will not conflict with the existing macro system if we do.