Hartmut Kaiser | 4 Oct 15:00

[Review] Phoenix review results

Hi all,

the Phoenix review is over and I counted 15 votes, 11 of which vote for
acceptance and 4 vote for conditional acceptance. Let me explain.

All reviewers stated that the outstanding quality of the library and its
documentation fully merit immediate acceptance. There is no direct concern
with regard to the library itself. Phoenix V2 is already in the Boost
distribution as a Spirit sub-library and has matured for a long time,
proving its stability and usability.

On the other hand, Phoenix provides functionality already covered by
Boost.Bind and Boost.Lambda. It is the general intention to use Phoenix as
the development ground for a new unified Boost library in this area. The
review discussions revealed quite some details and certain problems which
have to be resolved for this merger to happen. Joel has a full list of these
details and promised to address all of them before adding Phoenix to the
Boost SVN.

The library authors made clear from the beginning that the review of the
current Version 2 of the library is just a stepping stone towards this goal.
At the same time Eric Niebler presented a first version of a Proto based
Phoenix rewrite (referenced as Phoenix V3). It is the general consensus to
use Phoenix V3 as the basis for further development. At the same time
Phoenix V3 exposes the same interface as Phoenix V2 and passes all related
tests. 

This review formally was about Phoenix V2, but largely turned out to be a
discussion of the future of Bind/Lambda and how Boost should go forward in
this direction. Again, the general consensus here is that a) we need a
(Continue reading)

Joel de Guzman | 5 Oct 02:12

Re: [Review] Phoenix review results

Hartmut Kaiser wrote:

> In general, the review was valuable for what it accomplished. It moved us
> closer towards a unified Boost library in the domain of functional
> programming idioms. Thanks to Joel and Dan for the high quality submission
> and to all participating the discussion for their valuable insights!

Thank you Hartmut for managing the review. Thank you all who participated
in the review, those who joined in the discussions, and especially those
who gave full reviews. It was a very fruitful 2 weeks. It's a good chance
to learn more about what the community wants. As Hartmut says, it's more
about the future than the past and present. Indeed, that's how I envisioned
the review. Regardless of the outcome, I was determined to improve Phoenix.
As with Spirit and Fusion, it's a work of love.

It's very encouraging to see that it has now become an official Boost
library, after many years as a sub-library under Spirit. I did believe
that it merited the Boost status. I also knew that the review will be
tough due to it's unique position in the midst of excelent libraries
like Lambda and Bind, not to mention other FP libraries like FC++ and
newer libraries, like Egg.

Now it's time to grab a beer and celebrate :-)

Regards,
--

-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net
(Continue reading)

Eric Niebler | 5 Oct 02:36

Re: [Review] Phoenix review results


Joel de Guzman wrote:
> Now it's time to grab a beer and celebrate :-)

And to get (back) to work on Phoenix v3! ;-) Congrats.

--

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Joel de Guzman | 11 Oct 04:47

Re: [Review] Phoenix review results

Eric Niebler wrote:
> 
> Joel de Guzman wrote:
>> Now it's time to grab a beer and celebrate :-)
> 
> And to get (back) to work on Phoenix v3! ;-) Congrats.

Part of Phoenix' success is due to the easy extension mechanism.
It would be super awesome if you can find some ways to simplify
V3 extension to something as easy as V2's. I intend to apply
whatever technique you can come up with to Spirit2. Yeah, I'm
not happy with its extension mechanism too. Nevertheless, I
am starting a Spirit 2.1 using Phoenix V3 as the model.

Regards,
--

-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Robert Jones | 5 Oct 19:55

Re: [Review] Phoenix review results

On Sun, Oct 5, 2008 at 1:12 AM, Joel de Guzman
<joel <at> boost-consulting.com> wrote:
>
> ....Regardless of the outcome, I was determined to improve Phoenix.
> As with Spirit and Fusion, it's a work of love.
>

It is a pleasure to read someone writing about their programming work
with emotion and passion. Too often, as a community and as a
profession, we write in an objective, professional style and fail to convey
the pleasure we take in our work, and how much of ourselves we invest
in it. To read someone of Joel's stature doing this can only be an
encouragement to choose computers and programming as a rewarding
profession.

Oh, and congrats! As you say the bar on FP libraries is pretty darned high!

- Rob.
dan marsden | 11 Oct 10:51

Re: [Review] Phoenix review results

Joel de Guzman wrote:
>Eric Niebler wrote:
>>
>> Joel de Guzman wrote:
>>> Now it's time to grab a beer and celebrate :-)
>>
>> And to get (back) to work on Phoenix v3! ;-) Congrats.
>
>Part of Phoenix' success is due to the easy extension mechanism.
>It would be super awesome if you can find some ways to simplify
>V3 extension to something as easy as V2's. I intend to apply
>whatever technique you can come up with to Spirit2. Yeah, I'm
>not happy with its extension mechanism too. Nevertheless, I
>am starting a Spirit 2.1 using Phoenix V3 as the model.

I think the problem with the v2 extension mechanism is that we
exposed how the expression templates were implemented. That left
us with no choice but to make a breaking change in the extension
mechanism between v2 and v3.

IMO ideally any extension mechanism for v3 would not expose directly that
proto is the underlying ET engine. I'm not sure how practical this
will be to do though, as we may need a mass of indirection to avoid
exposing proto directly?

Cheers

Dan

      
(Continue reading)


Gmane