quote_expr, quote_tokens, etc. should not require an "ext_cx" to be in scope -- HOW TO FIX THEM

[jbclements]

There are a number of problems with our current quote_expr!, quote_tokens!, etc. macros. The first one is that they're cloaking/unhygienic. Fixing this is easy--just change the macro definition so that you have to supply an identifier as the first argument.

The second problem is that they really shouldn't work in the way that they do.

Specifically, these macros currently expand into ASTs that represent calls to the parser, thereby generating an AST. This discards all context/hygiene information, and is also inefficient, since you already have the AST that you're trying to protect.

Languages such as Racket just provide a language primitive called "quote-syntax" whose evaluation rule is literally the trivial one--a use of quote-syntax simply evaluates to the AST on the right hand side of the call.

What would it take to add this to Rust?

1. You'd need a new AST node called (say) quote_expr.
2. The typechecker would have to know that any quote_ast node trivially has the type ast::expr -- no checking required.

This should be less than a day of work for someone who really understands the system well. One question is whether you want to duplicate this work for each of the quote_... thingies, or make one that covers them all, with some kind of simple enum.

It appears to me that it would also allow us to throw out a huge amount of code--all of the quoting stuff that's in there currently.

[huonw]

It seems like this might lend itself to a solution for two problems: quoting and macros being only able to expand to expressions or (one) item (e.g. #4621). Specifically, something like:

enum SyntaxWrapper<T> {
    Plain(T),
    Quote(T),
    MacroInvocation(Mac)
}

type Expr = SyntaxWrapper<Exp_r>;
type Item = SyntaxWrapper<Item_>;
type Method = SyntaxWrapper<Method_>;
type Ty = SyntaxWrapper<Ty_>;
// ...

(It'd be nice to have GADTs to be able to express that MacroInvocation is impossible after expansion in the types, but such is life.)

However, I would imagine that this would have a big negative effect on downstream code, and we appear to be moving away from the spanned wrappers too, so this pattern may be deprecated.

[jbclements]

Since issues are forever, I should add that @graydon indicates that Rust used to have something like this, but that as he quite correctly points out, it doesn't solve quasiquoting. This is true; quasiquoting highlights the value of simplicity in ASTs. So, I still think adding a quoted-syntax AST node makes sense, but I see that you still need a nice way to mix computed and quoted elements to get quasiquote.

[steveklabnik]

I'm not sure what the situation is today. @kmcallister ?

[steveklabnik]

Triage: with no updates since 2013, and big changes planned to the syntax extension system, i'm going to give this one a close.