Welcome to Spirit

Thomas Heller has just completed the Phoenix Proto port. Another successful GSOC project!

I’ve been mentoring for GSOC for a couple of years now. This one is the best (the Fusion 0x project of last year’s GSOC was also highly successful, but it was Hartmut Kaiser who mentored that). Thomas is an amazing student! A++, if there’s such a thing.

Here’s Thomas’ post on the Boost mailing list:

Ladies and Gentlemen,

I proudly announce that the port of phoenix3 is completed! All  testcases pass! (some with minor modifications)

So, What is next? Here is my proposed schedule:

• fix some minor issues
• improve boost.bind compatibility: make all boost.bind testcases pass
• implement all boost.lambda testcases and make them pass, as far as it is reasonable
• add support for C++0x lambdas
• make interoperability testcases for std::function, boost::function
• adapt the documentation
• clean up code (some parts are a little messy as of now)
• improve compile time

Did I miss something?

This is a very tight schedule, I may not be able to finish all points during the GSoC period. Any help will be appreciated. Additionally a review of the current code is highly appreciated to point out some defects that might exist.

The code can be checked out at:
https://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3

I will be happy to answer your questions!

Additionally I would like to thank Joel de Guzman and Eric Niebler for their great assistance and initial designs!

So why is this relevant? Here’s more from Eric Niebler:

Let me expand a bit on Thomas’ post with my own perspective. Currently, the expressions created by Boost.Bind, Boost.Lambda and Boost.Phoenix2 are black boxes. You can pass them to std algorithms for evaluation, but that’s about it.

In contrast, the expressions created by Boost.Phoenix3 will the Proto expressions. If Phoenix3 is the compiler of a C++-in-C++ domain specific language, then the Proto expression is the intermediate form. It will be documented and part of the Phoenix3 API. The grammar for valid Phoenix3 expressions will also be documented and extensible. For the first time, we will have a way to generate C++-like expression trees, just like the C++ compiler itself does. We have a standard way (Proto) to traverse and manipulate them. Sure, you can just evaluate them as you could before, but now you can do much more. For instance, you can define your own Proto transforms to:

• Do various optimizations, just like a real compiler
• Add your own custom evaluation strategies for operations on your types
• Rewrite Phoenix3 expressions for parallel execution, or whatever
• ???!!!

Essentially, it means Phoenix3 is a white box, an open platform. Third parties can use just the Phoenix3 front end and intermediate form, substituting their own back ends to make the expressions mean and do completely different and domain-specific things.

Expect to see Phoenix3 expressions showing up in other DSEL contexts. It’s hard to predict how people will use this. The possibilities are really limitless.

We have a new page enumerating the best practices for using Spirit. Right now, there’s only one entry (update: there may be more by the time you read this), but as time goes by, we will be filling this page with more. If you have a short Spirit tip to share, this is the page. Add a comment and we’ll incorporate them.

See the “Best Practices” page here.

Awesomeness…

Michael Caisse of Object Modeling Designs designed this cool Spirit inspired T-shirt. I love it so much. If you like Spirit as much as we do, you can get one from Michael here: http://objectmodelingdesigns.com/swag.html