Hah, I thought about doing this at some point. I think it's cool that someone put the effort into it, Rust's macros are conducive for this sort of thing.
Rust macros are extremely impressive. This reminds me of Will Crichton's Lia library[0], which embeds a convenient matrix manipulation domain specific language inside of Rust. This seems like a very promising direction for fusing the low-level performance of Rust with the high-level readability and usability of a managed language. Exciting times.
It would be impossible to remove the `lisp!` on every form, as you have to actually invoke the macro.
You could make a build script that would read in lisp files, and then run them through a pre-processor of sorts before compiling. That's the closest thing, and it'd still require setting up that build.rs.
Just look at the progn expansion and create one like it that doesn't add the curly braces, and that ought to work I think; (perhaps call it "prog" or something).
This reminds me a little bit of rebol, and the concept of dialecting. So the language is composed of many DSLs called dialects each specialized for different things.
Interesting, I'm planning to implement a translator from a subset of Scheme to Rust. The source code will be Scheme plus extraneous forms for declaring types and borrow checker information / referencing, minus support for call/cc and other difficult to translate Scheme features. I want to develop a program in a Scheme interpreter then be able to compile it as a Rust program. Contact me if interested (and meet me in London via http://rustaceans.uk).
While not ideal, one tool for this situation is "cargo expand". It will expand your macros so that you can examine what code is being generated, and hunt down what might be happening.
17 comments
[ 4.4 ms ] story [ 42.9 ms ] thread[0]:https://github.com/willcrichton/lia
Then you'd have a lisp syntax on Rust that is not embedded. Is that correct?
You could make a build script that would read in lisp files, and then run them through a pre-processor of sorts before compiling. That's the closest thing, and it'd still require setting up that build.rs.
At that point, you would be better off using a Lisp implementation and its expander over a bunch of Lisp to Rust macros.
did not go well