Hacker News new | comments | show | ask | jobs | submit login

There are a few things that are annoying about writing macros* (in particular when I last checked there was no way to break the hygiene which is something that is occasionally useful for eg making lots of functions that follow a similar template) in Rust but in general I think they strike a really nice balance for a language with complex syntax:

1. Macros only happen in certain points and don’t need to be known to be parsed so parsers can be made which don’t need to understand macro syntax (or know which macros are in scope before parsing). I think this is better than e.g. ocamlp4 (writing a plugin for an alternative compiler frontend) or perl6 (subclassing the grammar of the language and adding your own rules which is a bit nice but also a bit crazy. Perl has the advantage of being so dynamic that any kind of analysis tools are not written to parse the code but to introspect it).

2. Macros don’t require any code to be compiled and then run at compile time. This also means that macros are not programs that have to understand the type of the ast and operate on it, something that would be particularly painful in rust for writing something simple. Languages where macros are not like this are ocaml with ppx, Rust, and Julia (where the ast is super vaguely defined and hard to work with, especially in the way it magically deals with module scoping and quoting, quaisiquoting, and “hygiene”)

3. The input to a macro is not a parse tree but rather a “token tree” which is essentially a sequence of tokens where delimiters are matched and converted into “tokens,” something that feels vaguely like TeX. the only other macro system that works at all like this is Lisp but that’s because the language (and ast) is sequences of tokens with parenthesised bits grouped into single tokens so it doesn’t really count.

4. Macros are based on rewrite rules. These make it quite hard to write macros but I think they’re the best we have for not needing to invent a huge language just to write macros in, and for having macros be hygienic. Scheme macros are also rewrite based but it is easier to understand how they work because the shape of their input it more obvious

One thing that makes me sad about rust macros is having to specify the “type” of things that are matched against, e.g. “expr”. I can see why it’s needed but it does feel somewhat limiting. Another thing is that macro invocations look different from the rest of the syntax so a macro feels like it’s tacked on rather than a part of the language.

* by macro I mean the kind made of rewrite rules and not compiler plugins




You might be interested in the work that Carl Mäsak is doing with 007 (http://masak.github.io/007/). It is the playground for developing future versions of macros in Perl 6.


I gotta say what I really like about macros are that ( and )s are matched. If you say:

  while ($($cond:tt)*) {
You'll actually match both

  while (true) {
and

  while (5 * (2 + 3)) {
. It counts the parenthesis :D


Even C preprocessor macros count parenthesis.

   MAC((here, have one argument), and then this second one)


But this is a requirement of the “you must be able to parse source code including macros without having to know how to expand macros” rule. Otherwise how would you know how to parse the following:

  foo!((x))
As

  foo! ( { ( x ) } )
Or

  foo! ( { ( x } ) )
With {} representing the argument to the macro.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: