Syntax extension

We currently have two stories with regards to macros. The reader should be aware that they don't even contradict each other: it's possible to build a system that naturally follows both stories.

#macro-style

The expander allows syntax extensions to add things to the syntax extension table.

Let #macro(macro_name, ...) be the macro that adds macro_name as a new macro. Presumably, the definition takes place in some pattern-matching language. It would be possible to write new syntax extensions #my_macro that use other languages.

(If rustc provides the ability to run Rust programs as a library, then it might even be possible to write #rust_macro, which would take a macro definition in Rust as an argument.)

The presence of these "second-generation" macros means that requiring "first-generation" macros to reside in a separate crate is not as onerous a burden, since same-file macro definitions are also possible.

single-phase-file-style

If one file (module?) import_for_syntaxes another file (module?), the exported functions are brought in as syntax extensions. Each file (module?) will only contain things in the same phase (to use a term from You Want it When?). We'll provide an API for syntax extensions, containing, at the least, some sort of syntax tree-manipulating functions. Ideally, syntax-quotation will also be present.

After that is complete, consider the following tasks:

• implement a term-rewriting (match/splice)-style macro system, possibly allowing macros to be used in the same file they are defined in.
• possibly allow macros that know the typeof expressions, or macros that preserve types. (Both of these are very hard. For the former, dherman believe that a simple subset may be possible. No one is very interested in the latter, but pauls things that they're mutually exclusive, just as a warning.)

Issues

Macro definition interface

A macro is at least a function from syntax to syntax. It may need an error reporting facility, and possibly a way to communicate to the parser to deal with the various nonterminals it may expect. It's possible that macros will transform syntax directly into new macros, to be fed back to the expander. That's a weird thing to do, though.

Nonterminals: expr/type/item/view_item

Will we use sigils to indicate which is which? Or will macros tell the parser what they expect?

Syntax

We've provisionally used # as a sigil to indicate a macro expansion. But it would be nice to have more flexibility than a flat list of syntactic arguments, so some other kind of delimiter (or possibly a way to specify keywords) may be necessary.

Expansion order

Expansion should be outside-in. This means that macros will need to expand code that has macro invocations in it. This means that the AST will need nodes representing macro invocations.