Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Practical Intro to Macros in Rust

danielkeep.github.io

Post reply on HN
Print view View original

21–26 of 26 posts

Re: A Practical Intro to Macros in Rust

#21

Post by steveklabnik »

FrozenVoid wrote: post #19
kibwen wrote: post #3

Note that this dates back to Rust 1.0, and although the macro system hasn't changed since then, plans are in the works to succeed this original system ("macros 1.0") with an improved one ("macros 2.0"), culminating in the deprecation of the original. The two systems won't differ that much, so the documentation will remain mostly the same and the transition should be very straightforward. The impetus for this is that…

Unfortunate, because metaprogramming is very important to code design. I won't want to abandon code just because v2.0 will get deprecated and shiny v3.0 will become the new standard next year. If Rust team cared about backward compatibility they could preserve old code by adding something like -std=rust1.0 which would not break code. Forcing people to rewrite any code(esp. complex macros) will not gain Rust any goodw…

To be clear, the new macros will be different than the old ones, and the two systems will coexist. People will be encouraged not to use the older macro style, but it's not going to be removed, so your code will not break.

There's no serious plans for a Rust 2.0, even though people bring it up from time to time.

Re: A Practical Intro to Macros in Rust

#22

Post by jordigh »

I still find myself most comfortable with D's compile-time function evaluation (CTFE) and mixins. In D, one use of mixins is more or less an eval function: take any string and evaluate it as code at the invocation site.

http://dlang.org/mixin.html

It's nice that you need very little new syntax to do compile-time tricks in D. The same syntax that works at runtime also works at compile time. If mixins worked with the AST instead of strings, it would be almost the same as Lisp macros.

I'm also kind of happy to see that D seems to have inspired Rust macros a little.

Re: A Practical Intro to Macros in Rust

#23

Post by kibwen »

VermillionAzure wrote: post #10

Hi. I'm a lead developer on the Shaka Scheme project that hopes to accomplish implementing Scheme R7RS, which also has hygienic declarative macros. R7RS Scheme has `syntax-rules` which is very similar in structure to this macro system. It's quite elegant as it is, in my opinion, but I'm also wondering how good the debugging facilities for it are. Are they good?

Scheme's syntax-rules was the direct inspiration for Rust's macro system, actually. As for debugging, I don't write my own Rust macros very often (and when I do, they're not very extensive), but I'd characterize the experience as "okay". Rust reports errors in macros as originating from the unexpanded line of code, which is useful for macro users but less so for macro authors. But you can ask the Rust compiler to emit the code that it sees post-expansion, if you want to inspect the generated output directly.

Re: A Practical Intro to Macros in Rust

#24

Post by Manishearth »

kibwen wrote: post #23
VermillionAzure wrote: post #10

Hi. I'm a lead developer on the Shaka Scheme project that hopes to accomplish implementing Scheme R7RS, which also has hygienic declarative macros. R7RS Scheme has `syntax-rules` which is very similar in structure to this macro system. It's quite elegant as it is, in my opinion, but I'm also wondering how good the debugging facilities for it are. Are they good?

Scheme's syntax-rules was the direct inspiration for Rust's macro system, actually. As for debugging, I don't write my own Rust macros very often (and when I do, they're not very extensive), but I'd characterize the experience as "okay". Rust reports errors in macros as originating from the unexpanded line of code, which is useful for macro users but less so for macro authors. But you can ask the Rust compiler to emi…

There's a `trace_macros` macro that you can use for debugging. It's somewhat useful.

Re: A Practical Intro to Macros in Rust

#25

Post by im_down_w_otp »

scott_s wrote: post #20
FrozenVoid wrote: post #19

Earlier quoted context omitted.

Unfortunate, because metaprogramming is very important to code design. I won't want to abandon code just because v2.0 will get deprecated and shiny v3.0 will become the new standard next year. If Rust team cared about backward compatibility they could preserve old code by adding something like -std=rust1.0 which would not break code. Forcing people to rewrite any code(esp. complex macros) will not gain Rust any goodw…

I don't think you're being charitable to the Rust team. They are quite vocal about how important they think API stability is. But they're also vocal about how important it is to get it right. For those reasons, they're upfront about what APIs are guaranteed to not change, and what APIs are still experimental. As an outsider, I think they do an excellent job of being transparent about the process.

Having used Rust off and on for the better part of 4 years through a lot of tumult and change, I agree with you.

In most cases the kinds of breaking changes and immaturities that the Rust core team communicates clearly to the ecosystem would be represented as nothing but silence and a giant dump of breaking changes suddenly in a lot of other ecosystems.

Sometimes the Rust team seems to pay a price for transparency, in that it gives people visibility, and thus something to make an opinion about and/or complain about. In an information vacuum there's nothing to opine about except the vacuum itself.

As annoyed as I often was, and occasionally still am, about different shapes of API stability in the language/libraries; I'm extremely happy the Rust team has maintained a commitment to developing everything out in the open.

Re: A Practical Intro to Macros in Rust

#26

Post by littlestymaar »

FrozenVoid wrote: post #19
kibwen wrote: post #3

Note that this dates back to Rust 1.0, and although the macro system hasn't changed since then, plans are in the works to succeed this original system ("macros 1.0") with an improved one ("macros 2.0"), culminating in the deprecation of the original. The two systems won't differ that much, so the documentation will remain mostly the same and the transition should be very straightforward. The impetus for this is that…

Unfortunate, because metaprogramming is very important to code design. I won't want to abandon code just because v2.0 will get deprecated and shiny v3.0 will become the new standard next year. If Rust team cared about backward compatibility they could preserve old code by adding something like -std=rust1.0 which would not break code. Forcing people to rewrite any code(esp. complex macros) will not gain Rust any goodw…

> I won't want to abandon code just because v2.0 will get deprecated and shiny v3.0 will become the new standard next year. […] Forcing people to rewrite any code(esp. complex macros) will not gain Rust any goodwill longterm.

That's why nobody is planning to do so anytime soon. The quote you posted explicitly says that.

Post reply on HN