
A Quick Intro to Rust Macros - untothebreach
https://danielkeep.github.io/quick-intro-to-macros.html
======
kibwen
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.)

~~~
qznc
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.

~~~
steveklabnik
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.

~~~
general_failure
Had to google that [http://www.hydrocodedesign.com/2014/04/02/higher-kinded-
type...](http://www.hydrocodedesign.com/2014/04/02/higher-kinded-types/)

------
rdtsc
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](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-...](http://benchmarksgame.alioth.debian.org/u64q/code-used-time-used-
shapes.php)

~~~
dscrd
"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!

~~~
rdtsc
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!

~~~
qznc
Maybe D should try to get into the game again. Unfortunately, D seems not sexy
enough for the maintainer.

[http://forum.dlang.org/post/hfuplv$1jjl$1@digitalmars.com](http://forum.dlang.org/post/hfuplv$1jjl$1@digitalmars.com)

~~~
igouy
Maybe you should help the D community to publish some measurements!

[http://forum.dlang.org/thread/lv7h1r$mg3$2@digitalmars.com?p...](http://forum.dlang.org/thread/lv7h1r$mg3$2@digitalmars.com?page=3#post-
juawuohxdfcxtbraejnv:40forum.dlang.org)

------
breckinloggins
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.

~~~
the_mitsuhiko
> 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.

~~~
kybernetikos
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.

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

------
maninalift
Readers may be interested to cf.
[https://en.wikipedia.org/wiki/Corecursion](https://en.wikipedia.org/wiki/Corecursion)

