3 ms·
It seems that the Rust macro system is inspired by a similar idea: In the first step (the "reader" in this article's terminology), the source is converted into
by codeflo 2y ago
It seems that the Rust macro system is inspired by a similar idea: In the first step (the "reader" in this article's terminology), the source is converted into something called a token tree.
A token tree is not a full parse tree with resolved operator precedence and whatnot. It only has child nodes for bracket pairs ((), [] and {}) and their contents, in part to determine where the macro call ends. Otherwise, it's a flat list of tokens that the macro (what this article would call the "parser") can interpret in any way it wants.
- wruza 2y agoSounds like Rust did to macros what I wanted long ago in C (and everyone frowned upon me for that). Lisps and sexprs aren’t exclusive to this. You can “load” the code into a var and modify it through regular data processing and then feed it to an executor. You just need language designers to implement that. This entire lisp homoiconicity religion bugged me since forever. It’s just a read-eval part of a loop which never had a requirement for everything to be represented as a Cons.
- moomin 2y agoI think you’re right. What LISP really brought to the party was a very simple token structure. This made it pretty easy to express manipulations of that structure and hence create whatever macros you like. This is instantly useful to the compiler writer because most of “LISP” is built upon more basic primitives. The disadvantage is the Jeff Goldblum “You scientists” meme.
- samth 2y agoIndeed, the Rust macro system was designed by people who had worked on the Racket macro system previously.