Writing Complex Macros in Rust: Reverse Polish Notation(blog.cloudflare.com)
blog.cloudflare.com
Writing Complex Macros in Rust: Reverse Polish Notation
https://blog.cloudflare.com/writing-complex-macros-in-rust-reverse-polish-notation/
80 comments
So it looks like people repeat how C++ templates are bad, and Rust macros are good. Can someone tell me what's the real difference? I'm not sure I get it, but I feel like both are good or both are bad.
C++ templates are intertwined with parsing and typechecking, while Rust has two separate features that cover the same ground: macros, which are purely parse time, and generics, which are purely run at typechecking time. This has advantages and disadvantages. The advantage of C++'s model is that it has one feature instead of two, and this allows for features like SFINAE that Rust has no analogue to. The advantages of Rust's model are that (1) the implementation is a lot simpler; (2) you can typecheck generics before they're expanded, which is a big improvement in ergonomics; (3) generics cover 90% of the use cases, so you rarely have to reach for macros.
C++ templates also aren't general purpose macros. For example, in Rust you can write a macro that takes an expression `e` and replaces it with `e + 1`.
However, I believe you can't do that with C++ templates. C++ template parameters can be types or primitive values, but not expressions. And the body of a template has to be some sort of declaration, e.g. a function definition or struct definition, but not an expression or statement.
However, I believe you can't do that with C++ templates. C++ template parameters can be types or primitive values, but not expressions. And the body of a template has to be some sort of declaration, e.g. a function definition or struct definition, but not an expression or statement.
Right, you can write a function that returns its argument plus one, but it couldn't e.g. evaluate `e` more than once (which both C and Rust macros can).
C++ templates are bad because they are untyped generics (e.g. C++ doesn't check that the key type for an hashmap is hashable, and instead you get a bunch of errors that there is no "hash" overload accepting certain arguments when you try to call a method on the hashmap).
C++ tried to add a type system for templates with "concepts" but it was scrapped.
Rust instead has properly typed generics instead using the trait system, resulting in proper static checking and proper error messages (although without higher kinded types and const generics currently, that C++ instead supports).
Rust also has a powerful macro system, which is unrelated to templates, although you can use them to have kinds of abstractions that the language doesn't support directly (like higher kinded types, const generic or abstracting over mutability), at the cost of having to explicitly perform instantiation, not having inference and having a higher cognitive burder.
C++ tried to add a type system for templates with "concepts" but it was scrapped.
Rust instead has properly typed generics instead using the trait system, resulting in proper static checking and proper error messages (although without higher kinded types and const generics currently, that C++ instead supports).
Rust also has a powerful macro system, which is unrelated to templates, although you can use them to have kinds of abstractions that the language doesn't support directly (like higher kinded types, const generic or abstracting over mutability), at the cost of having to explicitly perform instantiation, not having inference and having a higher cognitive burder.
> instead you get a bunch of errors that there is no "hash" overload
Since you get some kind of compile-time diagnostic, then effectively, the type is checked. Just, within static time, not as early as you'd like, with not as a relevant a diagnostic.
ISO C++ doesn't dictate the wording of diagnostics; a C++ implementation could work backward from that error, or do whatever else, in order to phrase the diagnostic in terms of a problem in the template.
Since you get some kind of compile-time diagnostic, then effectively, the type is checked. Just, within static time, not as early as you'd like, with not as a relevant a diagnostic.
ISO C++ doesn't dictate the wording of diagnostics; a C++ implementation could work backward from that error, or do whatever else, in order to phrase the diagnostic in terms of a problem in the template.
C++ templates are only typechecked for types that are actually instantiated. Rust generics are typechecked using the traits that the generic is declared with. That's a pretty big difference for people writing generic/templated functions though not as big of a difference for people using them.
Sure, also, C++ code is also typechecked only for files that you feed to the compiler and include in your image.
C++ templates being checked only for instantiated types makes them flexible. E.g. a template that accesses type::foo or instance.foo will work with anything that has a member named foo. That template argument doesn't have to have a declared relationship to any type which has foo, which would be an annoying restriction for the users.
Types that aren't instantiated don't exist. They don't correspond to anything in the executable image. Worrying about them is like a recording studio fussing over how much reverb to add to a one-handed clap.
C++ templates being checked only for instantiated types makes them flexible. E.g. a template that accesses type::foo or instance.foo will work with anything that has a member named foo. That template argument doesn't have to have a declared relationship to any type which has foo, which would be an annoying restriction for the users.
Types that aren't instantiated don't exist. They don't correspond to anything in the executable image. Worrying about them is like a recording studio fussing over how much reverb to add to a one-handed clap.
It makes them more flexible in the same way that dynamic typing is more flexible. A type error that doesn't execute doesn't really exist either.
It's fine to not worry about types that don't get instantiated if you are the only person ever instantiating a template, but that's obviously not always the case. If my template doesn't typecheck for a type that someone else wrote, I don't find out about it until they send me a bug report. With typechecking before instantiating, I find out about it as soon as I write it.
It's fine to not worry about types that don't get instantiated if you are the only person ever instantiating a template, but that's obviously not always the case. If my template doesn't typecheck for a type that someone else wrote, I don't find out about it until they send me a bug report. With typechecking before instantiating, I find out about it as soon as I write it.
Except it's not dynamic typing; everything that goes into the output image is type checked.
> A type error that doesn't execute doesn't really exist either.
Nope; that depends on what you mean by "doesn't execute".
Provably doesn't execute? As in: it is removable, dead code?
Or: doesn't execute because it's not covered by a test case? So that it could execute if a suitable input is found?
A template-generated type that is not instantiated doesn't execute because it doesn't exist. It's not in the image. There is no possible input to the program which can exercise it.
The code is basically not written. There is no need to diagnose bugs in code that isn't written.
Making users derive template arguments from a specific type is just stupidly "blubby". That C++ has typeless template parameters is one of the few sane things about the way it supports generic programming.
> With typechecking before instantiating, I find out about it as soon as I write it.
With type checking, that same user who would have run into a problem with the "typeless template" will simply find your template useless, and roll their own. In other words, same situation as before. The type error will still be there.
If you have a template that is intennded with foo-like arguments, and the user uses them with a bar-like object, that's going to be diagnosed one way or another.
If the generic arguments are weak, it will show up as some constraint violation when the template-generate code uses the the bar-like thing as if it were foo-like.
If the generic arguments are strong, the user instead gets an error that the bar-like thing is not a suitable argument to the template, which expects a foo-like.
It's the same either way; it's all static checking at the same static time and it doesn't change the circumstances under which errors occur. It just changes the amount of discipline needed to use the generic, and the accuracy/granularity of the diagnostic ("this thing is not a foo" versus "this thing here coming from a template parameter can't be used in this way in this piece of template generated code").
It's easier for the user to adjust the bar object to make it sufficiently foo-like for a given template, than to make it completely conform to the foo type.
> A type error that doesn't execute doesn't really exist either.
Nope; that depends on what you mean by "doesn't execute".
Provably doesn't execute? As in: it is removable, dead code?
Or: doesn't execute because it's not covered by a test case? So that it could execute if a suitable input is found?
A template-generated type that is not instantiated doesn't execute because it doesn't exist. It's not in the image. There is no possible input to the program which can exercise it.
The code is basically not written. There is no need to diagnose bugs in code that isn't written.
Making users derive template arguments from a specific type is just stupidly "blubby". That C++ has typeless template parameters is one of the few sane things about the way it supports generic programming.
> With typechecking before instantiating, I find out about it as soon as I write it.
With type checking, that same user who would have run into a problem with the "typeless template" will simply find your template useless, and roll their own. In other words, same situation as before. The type error will still be there.
If you have a template that is intennded with foo-like arguments, and the user uses them with a bar-like object, that's going to be diagnosed one way or another.
If the generic arguments are weak, it will show up as some constraint violation when the template-generate code uses the the bar-like thing as if it were foo-like.
If the generic arguments are strong, the user instead gets an error that the bar-like thing is not a suitable argument to the template, which expects a foo-like.
It's the same either way; it's all static checking at the same static time and it doesn't change the circumstances under which errors occur. It just changes the amount of discipline needed to use the generic, and the accuracy/granularity of the diagnostic ("this thing is not a foo" versus "this thing here coming from a template parameter can't be used in this way in this piece of template generated code").
It's easier for the user to adjust the bar object to make it sufficiently foo-like for a given template, than to make it completely conform to the foo type.
> With type checking, that same user who would have run into a problem with the "typeless template" will simply find your template useless
Unless you have a bug in your template that causes it to have a type error for a type that you didn't intend for it to have a type error for.
Unless you have a bug in your template that causes it to have a type error for a type that you didn't intend for it to have a type error for.
If the template works (is tested with) with a foo (base class), there is no reason it wouldn't work with something derived from foo. (If not, then there is some LSP issue in the foo type hieararchy; the generic as such is working.)
You might intend (without actually testing) that the template works with some bar also, not related to foo; the user tries it and finds otherwise, due to a bug.
With the typed generic, you just declare that it's for foo, and it refuses to work with bar (whether or not it has a bug which would actually prevent that in the absence of the declaration).
All the declaring, checking, instantiation, and the rest of it are all happening in the same time: static time. There is no difference like with static versus dynamic. Static versus dynamic is due to different times: what is done before running the program, versus during.
There is no verification difference between declaring that a template parameter may be of types foo | bar, and writing a typeless template which a test module then instantiates for foo and bar. Both are declarative mechanisms at work, played out statically. Just one way is more open-ended; it's not "sealed" against new instantiations.
You might intend (without actually testing) that the template works with some bar also, not related to foo; the user tries it and finds otherwise, due to a bug.
With the typed generic, you just declare that it's for foo, and it refuses to work with bar (whether or not it has a bug which would actually prevent that in the absence of the declaration).
All the declaring, checking, instantiation, and the rest of it are all happening in the same time: static time. There is no difference like with static versus dynamic. Static versus dynamic is due to different times: what is done before running the program, versus during.
There is no verification difference between declaring that a template parameter may be of types foo | bar, and writing a typeless template which a test module then instantiates for foo and bar. Both are declarative mechanisms at work, played out statically. Just one way is more open-ended; it's not "sealed" against new instantiations.
[deleted]
> C++ doesn't check that the key type for an hashmap is hashable
I thought it was possible to do something like this? (disclaimer: I don't use c++)
class Hashable { abstract char *hash() = 0; } template<typename T: Hashable, typename U> class Hashmap { vector<U> buckets; // etc. }
I thought it was possible to do something like this? (disclaimer: I don't use c++)
class Hashable { abstract char *hash() = 0; } template<typename T: Hashable, typename U> class Hashmap { vector<U> buckets; // etc. }
> C++ tried to add a type system for templates with "concepts" but it was scrapped.
concepts was merged into the C++2020 draft recently, so not entirely scrapped! I forget if it was full-blown concepts or "concepts lite" though.
concepts was merged into the C++2020 draft recently, so not entirely scrapped! I forget if it was full-blown concepts or "concepts lite" though.
Concepts are on track for C++20 and they are already available on gcc to play with.
Besides that, it is already possible to use typed templates in C++, at least with any C++14 compiler and even better on C++17, even if it requires a bit more of effort for the implementer of the generic code.
Basically by making use of type traits, static asserts, constexpr if and enable_if.
Yes, it isn't as clean as Rust but as shown by Andrei Alexandrescu with D, it opens the door for very powerful designs.
Besides that, it is already possible to use typed templates in C++, at least with any C++14 compiler and even better on C++17, even if it requires a bit more of effort for the implementer of the generic code.
Basically by making use of type traits, static asserts, constexpr if and enable_if.
Yes, it isn't as clean as Rust but as shown by Andrei Alexandrescu with D, it opens the door for very powerful designs.
But the C++20 concepts is only concept lite. It does not check the implementation of the template function that it only uses operations available for the conceps.
suppose you have a concept Hashable that is only enabled for type with a hash() function. But you can still in the code of your HashMap do a comparison with the < operator, which the Hashable concept don't ensure. In that case you woud only have an error at instentiation type for Hashable types that don't have '<'
In Rust, the compiler make sure that your generic function only use operations that exits in the traits declared in the function signature.
suppose you have a concept Hashable that is only enabled for type with a hash() function. But you can still in the code of your HashMap do a comparison with the < operator, which the Hashable concept don't ensure. In that case you woud only have an error at instentiation type for Hashable types that don't have '<'
In Rust, the compiler make sure that your generic function only use operations that exits in the traits declared in the function signature.
Those are like different concepts. While Rust macros work on the AST and take AST nodes as arguments C++ templates are a whole meta language that also allows for code execution. I would say that Rust macros mainly do code generation while C++ templates also allow for computation.
As a, slightly facetious, addition. I think Rust macros are better than either the C preprocessor or C++ templates because they're so bloody confusing.
They require someone with a great deal of energy, knowledge and will to win in order to tease anything useful out of them. This, I submit, is a feature. It dissuades the programmer who believes they are better than they are from being too clever by half.
There are worse things in the programming sphere than crap meta-programming but it does have its own circle in hell.
I appreciate that the Rust team are working hard to spoil my happy idyll but happy I remain for now.
They require someone with a great deal of energy, knowledge and will to win in order to tease anything useful out of them. This, I submit, is a feature. It dissuades the programmer who believes they are better than they are from being too clever by half.
There are worse things in the programming sphere than crap meta-programming but it does have its own circle in hell.
I appreciate that the Rust team are working hard to spoil my happy idyll but happy I remain for now.
I tend to agree with the argument that Rust macros are deliberately ugly so that people will only reach for them as a last resort (learning the hard-won lesson from Lisp, as it were), but there's no way that Rust macros are any more confusing than the C preprocessor or C++ templates. Have you ever tried to write a C macro that actually expands to what you want it to, in all possible contexts? And the less said about the horrors of C++ templates, the better. No, the fact that Rust macros have severe (deliberate) limitations is what makes them tractable; there's no shenangians comparable to `#define true false`.
Th Rust macro system is difficult to use. So it doesn't get used a lot. But when it does it tends to be used well.
The C preprocessor and C++ templates are not difficult to use. But they're both difficult to use well. So they get used. A lot. Badly.
The C preprocessor and C++ templates are not difficult to use. But they're both difficult to use well. So they get used. A lot. Badly.
C++ templates are used for two different features in Rust: generics, and a more broad "metaprogramming."
The other threads talk a bit about general metaprogramming, so let's talk about the other bit. On the generics side, here's an illustrative example, taken from http://en.cppreference.com/w/cpp/language/function_template
In Rust, here's the same function:
The fix is:
There are advantages and disadvantages to both approaches. In some senses, the tradeoffs are the same as any duck typed vs not situation: the C++ approach is far more flexible, but the Rust approach has stronger guarantees. We also chose the style we did because we prefer the nicer errors; C++ template errors are notoriously complex, though many say they get used to how to read them over time.
Additionally, neither languages' story is complete here. C++20 has a new feature called "Concepts" that gives you some degree of similar features here, but it's complex and I haven't read the version that was merged into the draft of C++20, so maybe someone else can elaborate on it. Rust is also adding a 'const fn' feature that gives you access to similar tricks to constexpr in C++, as well as more features for our bounded generics.
The other threads talk a bit about general metaprogramming, so let's talk about the other bit. On the generics side, here's an illustrative example, taken from http://en.cppreference.com/w/cpp/language/function_template
#include <iostream>
template<typename T>
void f(T s)
{
std::cout << s << '\n';
}
int main()
{
f(7);
}
In Rust, here's the same function:
fn f<T>(s: T) {
println!("{}", s);
}
fn main() {
f(7);
}
error[E0277]: the trait bound `T: std::fmt::Display` is not satisfied
--> src/main.rs:2:22
|
2 | println!("{}", s);
| ^ `T` cannot be formatted with the default formatter; try using `:?` instead if you are using a format string
|
= help: the trait `std::fmt::Display` is not implemented for `T`
= help: consider adding a `where T: std::fmt::Display` bound
= note: required by `std::fmt::Display::fmt`
error: aborting due to previous error
The fix is:
use std::fmt::Display;
fn f<T: Display>(s: T)
// or in near-future Rust, a slightly nicer syntax, still needs the 'use' line too:
fn f(s: impl Display)
There are advantages and disadvantages to both approaches. In some senses, the tradeoffs are the same as any duck typed vs not situation: the C++ approach is far more flexible, but the Rust approach has stronger guarantees. We also chose the style we did because we prefer the nicer errors; C++ template errors are notoriously complex, though many say they get used to how to read them over time.
Additionally, neither languages' story is complete here. C++20 has a new feature called "Concepts" that gives you some degree of similar features here, but it's complex and I haven't read the version that was merged into the draft of C++20, so maybe someone else can elaborate on it. Rust is also adding a 'const fn' feature that gives you access to similar tricks to constexpr in C++, as well as more features for our bounded generics.
Your example in C++17,
#include <iostream>
#include <string>
#include <type_traits>
class Display {
virtual std::string fmt() = 0;
};
template<typename T>
void f(T s)
{
static_assert(std::is_base_of<Display, T>::value, "Error: T must implement Display interface");
std::cout << s << '\n';
}
int main()
{
f(7);
}
<source>:12:7: error: static_assert failed "Error: T must implement Display interface"
static_assert(std::is_base_of<Display, T>::value, "Error: T must implement Display interface");
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:19:7: note: in instantiation of function template specialization 'f<int>' requested here
f(7);
^
1 error generated.
Compiler returned: 1
This is not really the same though, because the Rust version compiles after the bounds have been added:
use std::fmt::Display;
fn f<T: Display>(s: T) {
println!("{}", s);
}
fn main() {
f(7);
}
Totally! There's a lot of code out there that doesn't do this, even if it could. That's also a lot more code, so I imagine people do it less often as well.
Beyond that as well, you won't get an error if you don't use f(7), that is, if your main is empty, which would affect library authors.
Beyond that as well, you won't get an error if you don't use f(7), that is, if your main is empty, which would affect library authors.
Concepts (lite, the version that is still around) are "one-way." They constrain what types you can use as template arguments, but they do not constrain what templates can do.
Which means the templates themselves can still impose additional requirements based only on their internals, leading to the same bad error messages for users and lack of checking for library authors that we have without concepts.
Which means the templates themselves can still impose additional requirements based only on their internals, leading to the same bad error messages for users and lack of checking for library authors that we have without concepts.
Both make debugging harder. Rust, though, keeps a lot more safety in the whole process. The resulting code is syntactically what the macro author meant, by the types.
And, nobody really steps through code anymore. So a lot of the difficulty argument is moot.
And, nobody really steps through code anymore. So a lot of the difficulty argument is moot.
> And, nobody really steps through code anymore.
I don't follow. What other technique is in, compared to code stepping?
Sometimes I put a breakpoint in and step thru code to help me figure if something is working properly or maybe live-inspect the return value of something that comes from the outside world. Maybe I'm missing some new fundamental technique to dev/debug?
Thanks in advance. (genuine question)
I don't follow. What other technique is in, compared to code stepping?
Sometimes I put a breakpoint in and step thru code to help me figure if something is working properly or maybe live-inspect the return value of something that comes from the outside world. Maybe I'm missing some new fundamental technique to dev/debug?
Thanks in advance. (genuine question)
I have seen very few people actually hook up a debugger and step through code lately. This is particularly pronounced in many of the functional idioms that are making it into java and similar languages. Stepping through a loop is now much more involved, entering the stream is a step in, not just a step.
I don't actually have a lot of experience with the rust world, but the main complaint with macros is typically that you can't step through them easily.
With my getting downvoted, I'm assuming I'm wrong and that step debuggers are more common in rust than I was assuming. I think that makes me happy. If anyone has a good video demonstrating this level of tooling, I'd be interested.
I don't actually have a lot of experience with the rust world, but the main complaint with macros is typically that you can't step through them easily.
With my getting downvoted, I'm assuming I'm wrong and that step debuggers are more common in rust than I was assuming. I think that makes me happy. If anyone has a good video demonstrating this level of tooling, I'd be interested.
"printf debugging" vs "debugging" is an eternal struggle. Many people do both, in both C++ and Rust. There are many, many essays written about the pros and cons of both approaches.
Rust as a project is investing heavily in working towards excellent debugger support, because people do use it.
Rust as a project is investing heavily in working towards excellent debugger support, because people do use it.
Debugging in CLion with gdb and the intellij-rust plugin is already quite pleasant.
It even works remotely attached to bare metal embedded projects on stm32 microcontrollers!
Unfortunately debugging isn't available with intellij-rust in the free IDEA community edition.
It even works remotely attached to bare metal embedded projects on stm32 microcontrollers!
Unfortunately debugging isn't available with intellij-rust in the free IDEA community edition.
How well does it work with heavy use of macros? Specifically, what does it mean to "step into" a heavily macro based section? I'd be very interested in seeing examples.
I do, but Visual Studio debugger lets me chose what I step into to.
I think it is fair that my comment was clearly all encompassing where it should not have been. I am curious on the numbers, though. Just anecdotally, I have seen very few people use a step debugger.
Some of it may be situational. With how many microservices I'm dealing with, "stepping into" a call really needs to jump to another process quite often.
Anyone have numbers, by chance, on how many folks actually use a lot of these features?
Some of it may be situational. With how many microservices I'm dealing with, "stepping into" a call really needs to jump to another process quite often.
Anyone have numbers, by chance, on how many folks actually use a lot of these features?
Visual Studio also does remote debugging, including for services running on Azure, and recently introduced across containers.
Usually the problema is that many developers never learned what a visual debugger is capable of, and the typical command line interface in UNIX leaves little room for exploration if people aren't curious to learn about them.
For example, many aren't aware that gdb has a TUI that eases the experience.
Usually the problema is that many developers never learned what a visual debugger is capable of, and the typical command line interface in UNIX leaves little room for exploration if people aren't curious to learn about them.
For example, many aren't aware that gdb has a TUI that eases the experience.
I know you can do remote debugging. I mean the case where you have a breakpoint in one service, and it calls to another service. You can't really "step into" that. Best you can do is connect to both services and have cooperating breakpoints.
But, really, this is something I've never actually done. Reasoning about how the system should behave has been enough to get me by.
But, really, this is something I've never actually done. Reasoning about how the system should behave has been enough to get me by.
A scenario I have used it a lot was in debugging cooperating processes in UNIX, a couple of years ago.
When some condition took place, the problematic process would break into the debugger, while the others would be parked waiting for me to attach to them.
When some condition took place, the problematic process would break into the debugger, while the others would be parked waiting for me to attach to them.
I didn't actually try out the code, so I don't know whether it actually works regardless, but this looks really suspicious:
= note: expanding `rpn! { @ op [ 4 , 3 + 7 , 2 ] * }`
= note: to `rpn ! ( [ 3 + 7 * 4 , 2 ] )`
The trace_macros! stringifier isn't inserting parens when required: due to the use of 'expr' the macro is treating 3 + 7 as a single node X, and then the multiplication with 4 is, in the AST, X * 4 (i.e. correct). The thing that is being printed there is the recursive rpn invocation in the @op branch, and specifically the '$a $op $b', which is a "disconnected" sequence of AST items/token trees. Once it's forced to be parsed as an expression (that is, when matched against the recursive '$... : expr' rules), the printer handles it correctly. For instance, the last 'to' line of the output in the example you quote, or, if that example is changed to 'rpn!(2 3 7 + 4 * 5)', the trace_macros output includes:
...
= note: to `rpn ! ( [ 5 , (3 + 7) * 4 , 2 ] )`
= note: expanding `rpn! { [ 5 , (3 + 7) * 4 , 2 ] }`
...I'd say macroexpansion is precedence agnostic.
folding * over 4, 3+7, 2
folding * over 4, 3+7, 2
*/ 4, 3+7, 2
*/ 3+7 * 4, 2
*/ 2 * 3+7 * 4
=> 2 * 3 + 7 * 4
Rust macros strike me as closely related to Scheme hygienic macros; is there a compare-n-contrast anywhere?
The original designers of the macro system absolutely had Scheme firmly in mind (source: I was there). The most telling giveaway is that the identifier for declaring macros, "macro_rules", is a reference to Scheme's "syntax-rules". As for a comparison, Rust macros have to jump through hoops to account for the fact that Rust has syntax (and types), and the Rust system isn't entirely hygienic yet (work in progress).
[deleted]
I believe Rust took direct inspiration from Scheme (or at the very least functional languages in general).
Here is my ten minute implementation in TXR Lisp:
Trying rpn-compile at the REPL:
Trying rpn-compile at the REPL:
$ txr -i rpn.tl
1> (rpn-compile '(3))
(let* () 3)
2> (rpn-compile '(3 4 +))
(let* ((#:g0266 4)
(#:g0267 3)
(#:g0268 (+ #:g0266 #:g0267)))
#:g0268)
3> (rpn-compile '(3 4 + 5 6 + *))
(let* ((#:g0269 4)
(#:g0270 3)
(#:g0271 (+ #:g0269 #:g0270))
(#:g0272 6)
(#:g0273 5)
(#:g0274 (+ #:g0272 #:g0273))
(#:g0275 (* #:g0274 #:g0271)))
#:g0275)
4> (rpn-compile '(3 4 + dup *))
(let* ((#:g0276 4)
(#:g0277 3)
(#:g0278 (+ #:g0276 #:g0277))
(#:g0279 (* #:g0278 #:g0278)))
#:g0279)
(defstruct rpn-compile-time nil
temps
lets
stack)
(defun allocate-temp (rct)
(push (gensym) rct.temps)
(first rct.temps))
(defun compile-expr (rct expr)
(if (member expr rct.temps)
expr
(let ((temp (allocate-temp rct)))
(push ^(,temp ,expr) rct.lets)
temp)))
(defun compile-dup (rct)
(let ((top (compile-expr rct (pop rct.stack))))
(push top rct.stack)
(push top rct.stack)))
(defun compile-swap (rct)
(swap (first rct.stack) (second rct.stack)))
(defun compile-binop (op rct)
(let* ((left (compile-expr rct (pop rct.stack)))
(right (compile-expr rct (pop rct.stack)))
(sum (compile-expr rct ^(,op ,left ,right))))
(push sum rct.stack)))
(defvar *compile-table*
^#H(() (dup ,(fun compile-dup))
(swap ,(fun compile-swap))
(+ ,(op compile-binop '+))
(- ,(op compile-binop '-))
(* ,(op compile-binop '*))
(/ ,(op compile-binop '-))))
(defun rpn-compile (exprs)
(let ((rct (new rpn-compile-time)))
(each ((word exprs))
(iflet ((fun [*compile-table* word]))
[fun rct]
(push word rct.stack)))
^(let* ,(reverse rct.lets) ,(first rct.stack))))
5> (defmacro rpn (. exprs) (rpn-compile exprs))
rpn
6> (rpn 2 2 +)
4Does the evaluate at compile time to a constant or does it produce that series of let bindings?
Nope; it makes the let bindings. The job of reducing to a constant is better left to the processing of the let rather than duplicated in the macro.
If you have a compiler which can reduce (let ((x 3)) ((y 4)) (+ x y)) to 5, why replicate that in a macro.
If you do not have one (as is the case here), then it's better to work on getting one than compensating for it in macros.
Yet, with the following small change to compile-expr, whereby we avoid generating temps for constant expressions, we can at least get some nicer-looking output:
If you have a compiler which can reduce (let ((x 3)) ((y 4)) (+ x y)) to 5, why replicate that in a macro.
If you do not have one (as is the case here), then it's better to work on getting one than compensating for it in macros.
Yet, with the following small change to compile-expr, whereby we avoid generating temps for constant expressions, we can at least get some nicer-looking output:
(defun compile-expr (rct expr)
(cond
((member expr rct.temps) expr)
((constantp expr) expr)
(t (let ((temp (allocate-temp rct)))
(push ^(,temp ,expr) rct.lets)
temp))))
1> (rpn-compile '(3 4 + 5 6 + *))
(let* ((#:g0266 (+ 4 3))
(#:g0267 (+ 6 5))
(#:g0268 (* #:g0267 #:g0266)))
#:g0268)Rust is probably the most advanced programming language with the worst syntax. Prolog and Erlang are a joy after Rust.
What is so terrible about the syntax? My biggest problem with Rust isn't the language, but the tooling which is still not quite there yet.
I find the syntax ok, and you do get used to the snake_case.
I find the syntax ok, and you do get used to the snake_case.
My impression has always been that it probably feels right at home for people with mathematical backgrounds, and mildly line-noisy for people coming from traditional programming backgrounds.
Stuff like this:
Stuff like this:
fn map<T, U, F>(vector: &[T], function: F) -> Vec<U>
where F: for<'a> Fn(&'a T) -> U {
...
While I like the functional style you actually did bring up one of the cases where I find the syntax a bit too much. Why can't we have the functional interface information on F directly in the signature?
Why not something more akin to ML?
Why not something more akin to ML?
fn map<T, U, 'a>(vector: &[T], function: &'a T -> U) -> Vec<U>I'm there with you. Have you found something consistent/stable to debug Rust code? I find the integration with VS:Code to be quite flimsy and friends have been saying that's like the pinnacle of Rust tooling right now, to have a fully loaded VS:Code with the Rust plugins...
We're still committed to improving tooling, so please file bugs!
I've used the "Native Debug" extension with VS: Code in the past.
I've heard that if you have a CLion license, it (with the Rust plugin) is pretty solid at debugging, but I don't own one of those.
I've used the "Native Debug" extension with VS: Code in the past.
I've heard that if you have a CLion license, it (with the Rust plugin) is pretty solid at debugging, but I don't own one of those.
Yes sir! You can rest assured I'll find something to contribute to the Rust ecosytem, be it bug reports, translations! I haven't been as thrilled as I am right now with a new language since I was a kid actually taking my first steps into programming (MS-DOS and Turbo Pascal days). I wanna see Rust take off and take a big slice off the 'most used languages throughout' pizza chart :-)
o/
o/
I know you are. I didn't mean to take a jab at you. Rust is amazing for how young the language still is. I also don't have a CLion license, but I've also heard from multiple sources that that is right now the best IDE.
What do you mean by "Native Debug" extension for VSCode? The normal Rust plugin built on top of Racer often shows Racer as crashed, and doesn't underline errors while typing. It also doesn't really seem to know the type of a variable most of the time. I'm writing in too many languages at once. Autocompletion usually gives me enough of a hint that I remember what to type.
VSCode being my favorite editor, so I'm glad that I don't need to install another IDE right now.
EDIT: I just checked it out, and apparently you can install the Rust plugin with IntelliJ Community Edition. Which is free.
What do you mean by "Native Debug" extension for VSCode? The normal Rust plugin built on top of Racer often shows Racer as crashed, and doesn't underline errors while typing. It also doesn't really seem to know the type of a variable most of the time. I'm writing in too many languages at once. Autocompletion usually gives me enough of a hint that I remember what to type.
VSCode being my favorite editor, so I'm glad that I don't need to install another IDE right now.
EDIT: I just checked it out, and apparently you can install the Rust plugin with IntelliJ Community Edition. Which is free.
It's cool! I didn't take it as a jab :)
I meant this extension: https://marketplace.visualstudio.com/items?itemName=webfreak...
> The normal Rust plugin
Which one are you talking about? There are three of them: one is abandoned.
> you can install the Rust plugin with IntelliJ Community Edition. Which is free.
My understanding is that you can install it, but it does not include debugging support, that's what you have to pay for.
I meant this extension: https://marketplace.visualstudio.com/items?itemName=webfreak...
> The normal Rust plugin
Which one are you talking about? There are three of them: one is abandoned.
> you can install the Rust plugin with IntelliJ Community Edition. Which is free.
My understanding is that you can install it, but it does not include debugging support, that's what you have to pay for.
It's just the plugin called Rust. I tried the other ones, but they were not better.
>it does not include debugging support
That's a bit sad, but I haven't had debugging support in VSCode until now. I'd pick good code completion and error hints over debugging. Both would be nice though.
How do you configure that Native Debug plugin for Rust?
>it does not include debugging support
That's a bit sad, but I haven't had debugging support in VSCode until now. I'd pick good code completion and error hints over debugging. Both would be nice though.
How do you configure that Native Debug plugin for Rust?
Gotcha, yeah it's RustyCode that's the outdated one. Rust(rls) is the one provided by the Rust team.
> How do you configure that Native Debug plugin for Rust?
exactly the same way that it says on the page; choose gdb or lldb, change target to point to the executable, and you're good to go.
> How do you configure that Native Debug plugin for Rust?
exactly the same way that it says on the page; choose gdb or lldb, change target to point to the executable, and you're good to go.
Prolog and Erlang are untyped. Er, dynamically typed. That changes quite a lot.
I personally find Rust quite a joy to read.
[deleted]
RISP
It looks like Rust doesn't have your dad's Lisp macros and more like C-style macros on steroids. Disclaimer: I haven't read The Book.
I don't think "C-style macros on steroids" is at all a good description. Rust's macros and C's really aren't that similar.
If you want a short introduction to what Rust's macros actually are then try this: https://danielkeep.github.io/practical-intro-to-macros.html#...
If you want a short introduction to what Rust's macros actually are then try this: https://danielkeep.github.io/practical-intro-to-macros.html#...
Well C macros work at the text-level, Rust macros run at the AST level (but not the type level, that is you cannot construct syntactically incorrect stuff but you can construct wrong-typed stuff).
So I don't really know lisp macros but I guess it's still closer than to C.
So I don't really know lisp macros but I guess it's still closer than to C.
Rust macros actually work more at the token level than at the AST level.
They work on both - for example, if you specify $expr:expr, it will actually parse it as an expression node and won't allow to simply pass it into another macro as $pat:pat because of AST node type mismatch even if actual tokens are still compatible.
That's a good point. What I was trying to get at is that Rust macros don't let you manipulate ASTs in any straightforward way. So they are not best thought of as AST -> AST transforms.
Oh I see, thx !
Rust macros are Scheme macros, there's no similarity to C.
There is a common set packages [0][1][2] that provide macros that are more similar to lisp-style macros (when operating on structs). [2] in particular implements quasi-quoting in rust.
[0]: https://doc.rust-lang.org/proc_macro/index.html [1]: https://github.com/dtolnay/syn [2]: https://github.com/dtolnay/quote
[0]: https://doc.rust-lang.org/proc_macro/index.html [1]: https://github.com/dtolnay/syn [2]: https://github.com/dtolnay/quote
Would Lisp macros make sense in language that is not homoiconic?
Many Lisp dialects are not homoiconic, as defined in the Wikipedia page for "homoiconic".
Homoiconic means that procedures are stored in representation in which they are written, or more or less.
A Lisp that compiles everything entered at the REPL isn't homoiconic. The input looks like (lambda (...) ...), but the storage is some block of x86 machine code with an environment vector.
POSIX shells are homoiconic. When you type set, you see your functions, in source code form (modulo reformatting).
The thing you want for metaprogramming is a smart internal representation of program text (not same as the external one).
Homoiconic means that procedures are stored in representation in which they are written, or more or less.
A Lisp that compiles everything entered at the REPL isn't homoiconic. The input looks like (lambda (...) ...), but the storage is some block of x86 machine code with an environment vector.
POSIX shells are homoiconic. When you type set, you see your functions, in source code form (modulo reformatting).
The thing you want for metaprogramming is a smart internal representation of program text (not same as the external one).
Fine. Would lisp macros make sense in a language that isn't fully parenthesized?
Factor https://factorcode.org/
by comparison to gp's article Facotr macros are easy because instead of knowing exactly where and what the arguments are in Factor the reader doesn't have to care.
by comparison to gp's article Facotr macros are easy because instead of knowing exactly where and what the arguments are in Factor the reader doesn't have to care.
Yes: https://www.cs.utah.edu/~rafkind/papers/honu-2012.pdf
Honu is a language with Javascript-like syntax, but has support for syntax-case style macros.
Honu is a language with Javascript-like syntax, but has support for syntax-case style macros.
They're actually closer to syntax-rules in Scheme.