**NO** `macro` support in 6.e

[lizmat]

With 6.e and full RakuAST support drawing near, the question about what to do with the current experimental implementation of macro.

Although one of the reasons of creating RakuAST was to be able to create a better macro experience. And it probably will happen sooner or later.

But at the moment of this writing, the "macros for Raku" project Alma has been dormant for 7 years now. And pretty much predates the idea and development of RakuAST completely.

So even though one could argue we haz the tools to create macros, nobody really has a clear idea of what macros in Raku should look like, and how these new tools should be used to achieve that.

Since a 6.e release has been in the making for more than 7.5 years now, it feels that trying to figure out how to implement macros in Raku before releasing 6.e, is a BAD idea.

Therefore it feels that the best way forward, is to not have any macro support in 6.e. Which would allow us to figure out how to implement them. Possibly by slangs in modules first. And possibly incorporate that in 6.f, which should only take one, maybe 2 years.

On behalf of the Raku Steering Council I can say that the RSC is heavily leaning towards this approach: no macros in 6.e, let developers figure it out in slang / module land on the way to 6.f.

[raiph]

I fully agree with Liz's summary.

That said, I wanted to slightly shift how people think about one thing:

the "macros for Raku" project Alma has been dormant for 7 years now.

Carl Mäsak (Alma's author) is as fun and friendly as always and he's never stopped developing his understanding of issues relevant to Raku macros. Of particular note, from a 2021 comment:

This effort should now definitely align itself with @jnthn's RakuAST effort

There have been many comments since then, including several replies in 2024 and 2025 by Carl to posts by me related to RakuAST and macros post 6.e.. (And another long time Raku friend, Vendethiel, posts there too.)

---

In summary, dear reader, definitely do not let Alma stop you making your Raku macro module. Indeed, consider reaching out to Carl to help you start making it. 🚀

[librasteve]

@raiph thank you (as always) for the thoughtful and thought-provoking comment. I vaguely remember reading about 007 a while ago and wishing that it was already there for Physics::Unit.

The story was that it needs something like 268 objects of class Physics::Unit instantiated on program start. The early development explored the space:

• just build all the objects on program start (ie read the definition files, parse them with Grammar, make each object) => 30sec start up time
• put the objects in a separate .rakumod so they can be precomped (forget why this wouldn't work)
• make the objects during build, write them all as .raku and then just ingest the raku files at compile time => fragile and a build / dev cycle PITA
• refactor so that objects are lazy - the current solution - so the first time you say ^<3 km> .in "yds", you make km, ft and yd objects and that incurs runtime cost instead

Oh to have had macros and not have to choose between compile time pain and runtime pain.

So it is a great pleasure to be reminded of 007 which I gather is now renamed ALMA.

I have some questions:

1. does ALMA run on current RakuAST?
2. where can I find a getting started?
3. where can I learn it?
4. how can I check it supports my use case (^^) and maybe contribute to the final dev't?

And to echo your conclusion - it would be excellent to see ALMA get some love immediately as a module and even see it drop quickly as maybe 6.f.PREVIEW soon after we get 6.e RakuAST out of the door.

[raiph]

Hi @librasteve,

does ALMA run on current RakuAST?

No, that's not at all what Alma is about. To quote Carl from 2018:

It'll be a merge of ideas/concepts/techniques rather than of codebases.

That's why I'm saying anyone creating Raku macros, or anything like that, should say 'Hi' to Carl and see what happens.

where can I find a getting started? where can I learn it? how can I check it supports my use case?

I've opened an issue Raku 6.e and macros in the Alma repo that links back to my first comment above and asks Carl to read my comment, then yours, and then this one.

I really just wanted to convey to Rakoons that I think Carl is the deepest well of knowledge in the once-or-back-to-the-future Rakoon community related to work on Raku macros.

Carl spent years exploring the algoloid (or Raku) with macros space while waiting for Raku to get to the point at which it, and Rakudo, were actually ready for macros.

As far as I know he remains fascinated by this space, remains highly knowledgeable about it, is highly capable as a coder, is a good productive organizer of coding projects, and is as friendly as ever.

In summary I'm saying that, at the very least, Rakoons interested in macro-ish things should say 'Hi' to him.

[librasteve]

@masak o/

[masak]

@librasteve Ahoy.

An attempt at a quick reply to all of the above: Alma has indeed been dormant, code-wise, for about seven years now. I consider the code base to be antiquated in terms of the understanding that has been encoded into it. During this time, there has been a consistent murmuring activity in the issues — easy to miss, especially as some of it has happened in closed issues. I won't link to them; if someone is interested enough they can find them.

There was an effort a couple years ago, by me, at trying to write a better/more complete specification for Alma. This is far more doable than with Raku. I would say I partially succeeded, both in terms of spec coverage (not yet complete) and in terms of spec precision (human-readable prose trying to be precise).

But then, last year, I accidentally hit on something with a new experimental language Mozzarella, which you can think of as a minimalist Alma, perhaps. Mozzarella was implemented spec-first, which means that there is a very close (but still informal/un-verified) connection between spec and implementation. This, it turns out, worked really well as a development model, and in retrospect is what I should have done for Alma as well. It's a little bit similar to An Incremental Approach to Compiler Construction by Abdulaziz Ghuloum. (Although Mozzarella is still evaluator-based, and not yet a compiler.)

This issue is about macros for Raku. To bring the above back to that point, with Mozzarella and its "blade spec"-driven approach, I have gained a much better appreciation of macro expansion, the surrounding mechanisms, the exact role of quasiquoting and unquotes, and hygiene. I agree that RakuAST was the big missing piece for Raku, and that macros for Raku should definitely take RakuAST as a starting point. I will see if I can contribute my recent understanding of things somehow to RakuAST. I have very little familiarity with RakuAST, but I have every reason to believe it's a good starting point. Where I could probably contribute is with the story for hygiene/unique symbols.

Full disclosure: Mozzarella blade spec 32, about macro hygiene, is not yet written and not yet implemented. There is a design document about the general approach (tl;dr: strings are not enough). The rest is floating around, restlessly, in my head for now. Hoping to get there within the next few weeks.

Is Mozzarella just Alma, restarted? No; at the core of the code quotation system is a simplification which you won't find in either Raku or Alma. In Raku and Alma, code quotes have what's called "cross-stage persistence" (a term by Alan Bawden, which you'll stumble over if you dive too deep into Alma's issues): stuff in the quote can reference bindings in the macro outside the quote. Mozzarella drops this part, which makes the macro system simpler, but also not an exact replica of Alma and Raku.

[librasteve]

@masak great to hear that you are happy to help out!

I have read a little of the background materials from https://github.com/masak/alma - very good to see that Alma is implemented as a Raku grammar. I am not yet at the point that I understand "where's the code?" and "what needs to be done now?" (I can guess eg that maybe refactor or rewrite ALMA to work with modern RakuAST (plus classes please) but you also state that RakuAST macros and ALMA are not the same thing). Anyway I am sure that that will come out in the wash. Please let us know how and when we can join in and help.

We’ve been expecting you, Mr Bond.