A Quick Intro to Rust Macros

https://danielkeep.github.io/quick-intro-to-macros.html

by untothebreach • 12 years ago

128 38 12 years ago

danielkeep.github.io

Great article but I wouldn't call this quick. It's quite in depth.

I'd love to see the exclamation mark requirement removed from the rust spec. It makes macro invocation feel "wrong" or "special" in a subtle way and betrays a lack of confidence in the macro system.

I'd rather the language designers assume that future tooling for IDEs and editors will syntax highlight macros.

rayiner2• 12 years ago

It makes me thing it signals mutation.

Dewie• 12 years ago

Because that's the convention in lisp?

the_mitsuhiko• 12 years ago

It makes macro invocation feel "wrong" or "special" in a subtle way and betrays a lack of confidence in the macro system

But a macro invocation is special. The syntax within a macro does not follow Rust rules, so if macros would not be marked properly it would be incredibly confusing for a user. Let alone that macro imports are different by the very nature of their behavior.

eddyb• 12 years ago

Not to mention it would be difficult, if not impossible, to parse in the first place (the contents of a macro invocation are stored as token trees within macro AST nodes, within the regular AST).

kybernetikos• 12 years ago

I think that the 'call-by-name' behaviour in Scala is confusing, because you can write something that you think will execute once but actually, it might execute multiple times and there's no obvious marker that it's special. When you have something that is potentially major, you generally don't want it to be invisible.

AndyKelley• 12 years ago

Macro invocation is special. It's significantly more readable to know whether you're calling a function or invoking a macro.

kibwen3• 12 years ago

Macros have a freeform syntax, with the only restriction being that delimiters within have to be balanced. I don't see how an IDE could provide general syntax highlighting for them.

whyever• 12 years ago

The IDE could parse the macro definition and highlight accordingly. (It would know where to expect an identifier and where to expect an expression etc.)

JoshTriplett• 12 years ago

That's actually a feature of Rust that I liked the moment I saw it. In particular, the forced '!' suffix makes macros stand out as something that might potentially introduce non-trivial control flow; for instance, the try! macro does an early-return of the containing function on failure. In C, putting control flow in a macro is generally considered poor form; in Rust, it becomes much more sensible precisely because of the macro naming convention.

stormbrew• 12 years ago

I'm not sure I agree with this. Or at least, I'm not sure I think this will hold true once macros are used for more than control flow mechanisms, which are approximately half of the uses of the macros in the stdlib right now as far as I can see. After all, most C style guidelines do insist on some way of differentiating macros, commonly making them all-caps, but it makes it no less sketchy to throw a return into a macro.

frowaway0012• 12 years ago

+1. ! is the worst part of Rust macros.

There is just a terrible mismatch between the use-case macros were originally intended for (embedding different languages) and how they are mainly used now (emulating varargs).

The current arguments from Rust people are mainly defensive in that area, but maybe they will revisit this as the community matures.

kibwen3• 12 years ago

  > There is just a terrible mismatch between the use-case 
  > macros were originally intended for (embedding 
  > different languages) and how they are mainly used now 
  > (emulating varargs).

This is incorrect. I can't think of any macros that are used to paper over the lack varargs (`println!` certainly doesn't count, because even if Rust had varargs you'd still need a macro here to do typesafe compile-time string parsing).

In any case, varargs can already be trivially emulated using vectors (which afaict is essentially what Go does, but Go has sugar for it). Macros would be overkill for this use case.

pornel• 12 years ago

I used to think so too, especially because very basic examples with `printf!()` look "odd", but I started to like it: it gives me confidence that regular function calls won't do anything bizarre.

It's a warning that there's "magic" going on. It makes it clear that there's a lot of quirky compile-time type checking trickery behind printf, it tells that regex is going to be precompiled, etc.

malkia• 12 years ago

It was peculiar at first with me, but I think I like it now.

Felt nearly the same way with "recur" in "clojure", instead of calling the function name recursively and pray the compiler would do the proper tail call optimization (elimination), but recur forces you to always get it right.

rdtsc3• 12 years ago

Very cool stuff. I started to play with Rust some more and started to really like it. Haven't gotten to macros yet.

I've been reading the official guides. Those helped clear up some difficult points for me: lifetimes and interfacing with lower level code.

http://doc.rust-lang.org/#guides

Also in what seems like a very short time, Rust community addressed the entries in Shootout Computer Benchmark game. Those are toy scores and one should not take them seriously. But unfortunately people do. So they made those fast.

http://benchmarksgame.alioth.debian.org/u64q/code-used-time-...

dscrd• 12 years ago

"Those are toy scores and one should not take them seriously."

People keep saying that about The Shootout, but I don't think so. They reflect the combination of two qualities: the main implementation of the language, and the community around the language. It's way too cynical to say that the results cannot be taken seriously -- they just have to be taken carefully.

For instance, we can see that the Rust community was able to make their runs quite snappy quite easily, even though the implementation isn't even ready yet. That's impressive!

rdtsc3• 12 years ago

They are toy examples as far as proxies for actual performance in real life. Unless real life code is a lot of n-body computations and FASTa searching, and it is run on a Debian OS with 4 core 64 bit machine (or other 3 configurations) performance need to be measured on a representative workload.

But what I was getting at is that those scores are non-toy like and important for PR purposes. And as you said, they represent how active or caring the community is (and how sensitive it is to its _perceived_ performance).

So kudos to Rust community!

igouy5• 12 years ago

The results are exactly what they claim to be.

What you believe they reflect is not a claim made on the website.

igouy5• 12 years ago

When you cannot get the project name right, why should we pay any attention to what you say about the benchmarks game?

rdtsc3• 12 years ago

why should we pay any attention to what you say about the benchmarks game?

I very much appologize and humble myself before the almighty benchmark gods. Please forgive me.

kibwen3• 12 years ago

I think it's prudent to reinforce that macros in Rust are currently very wobbly. It would be an epic folly to stabilize them anytime soon, which means that any forthcoming stable Rust 1.0 release won't feature user-defined macros (stdlib macros like `println!` and `regex!` et al will still be available in 1.0, because only their interface needs to be stabilized, not their definition mechanisms). You'll have to stick to the nightly releases if you want to define your syntax extensions and such, at least until we straighten out this towering pile of hacks.

That said, we're looking at interim ways of providing some sort of relief for people who want to metaprogram in Rust 1.0. There aren't any concrete plans yet, but we love the idea of user-defined macros and we're not going to leave people out in the cold if we can help it.

(And perhaps you're wondering why we don't delay Rust 1.0 until macros are ready? Because the rest of the language works (or very soon will work) just swimmingly, and it doesn't make sense to deny stability from people who can live without macros (whose definition mechanisms can be introduced without breaking backwards compatibility). Rust 1.0 will be only the beginning of a gradual transition towards ecosystem stability, not a sudden leap.)

qznc2• 12 years ago

I would assume that there will be a huge temptation to rewrite the standard library once macros are a normal language feature. For the language macros might be purely additive, but for the API designer it is a big difference.

steveklabnik3• 12 years ago

Given that Rust developers have had macro access for a long time now, I don't think that's true. Or at least, I don't think that the standard library would be any different if macros were stable. Something like HKT would, though, and is already being considered with regards to the standard library's design.

tempodox• 12 years ago

This clarification is very much appreciated, thank you :)

maninalift• 12 years ago

Readers may be interested to cf. https://en.wikipedia.org/wiki/Corecursion

A Quick Intro to Rust Macros

Related Stories