Jul 23

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:

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.

4 Responses to “Phoenix3 GSOC project”

  1. anders li says:

    It sounds good really. May I know the relationship of this new phoenix and spirit? Whether phoenix3 will have some effects on the spirit ? Could anyone explain more on it ? Is the spirit now also in the process to its new version like spiritV3 ?

  2. Joel de Guzman says:

    This won’t affect Spirit. Not just yet.

  3. Viet says:

    Sounds great! Looking forward to playing with Phoenix3 for the next year’s Boost release.

  4. Viet says:

    Any plans to write a tutorial on Boost Spirit 2.4? It’d be great if you are planning for one.

Leave a Reply

preload preload preload