Show HN: A Rust macro that parses Java-like syntax and runs it as a Rust program
1–10 of 35 posts
Re: Show HN: A Rust macro that parses Java-like syntax and runs it as a Rust program
#2[deleted]
Re: Show HN: A Rust macro that parses Java-like syntax and runs it as a Rust program
#3I don't know what I would do with this yet, but this is certainly a cool feat!
Re: Show HN: A Rust macro that parses Java-like syntax and runs it as a Rust program
#4But the issue with Rust ins't the syntax, it's where you need to change your entire thought model to match what Rust expects.
Well, ok, the syntax can be pretty horrific at times, but going to something Java-like doesn't seem like much improvement.
Re: Show HN: A Rust macro that parses Java-like syntax and runs it as a Rust program
#5But the issue with Rust ins't the syntax, it's where you need to change your entire thought model to match what Rust expects. Well, ok, the syntax can be pretty horrific at times, but going to something Java-like doesn't seem like much improvement.
This isn't really intended to be used for any actual code, it's just a fun exercise.
Re: Show HN: A Rust macro that parses Java-like syntax and runs it as a Rust program
#6I was actually just toying with a similar thing myself. I'm experimenting with a system that generates abilities for a game within certain design parameters, then tests the games' balance by running lots of example games. I figured compiling a DSL via macro compiled down would be worth the upfront cost given how much testing I planned on giving each generated variant. Thanks for laying some groundwork in this part!
Re: Show HN: A Rust macro that parses Java-like syntax and runs it as a Rust program
#7How well do LSP implementations cope with complex macros like this?
Re: Show HN: A Rust macro that parses Java-like syntax and runs it as a Rust program
#8Reminds me of this cool hack: a 6502 assembler as a rust macro.
Re: Show HN: A Rust macro that parses Java-like syntax and runs it as a Rust program
#9There 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
Re: Show HN: A Rust macro that parses Java-like syntax and runs it as a Rust program
#10Cool. On the other hand, projects like these suggest to me that Macro systems like Rust's are a bit too powerful.
Not that I know how to make it just enough less powerful.