headers
Hartmut Kaiser | 22 Sep 01:55

[Review] Phoenix review starts today, September 21st

Hi all,

The review of Joel de Guzmans and Dan Marsdens Phoenix V2 library starts
today, September 21st 2008, and will end on September 30th. 
I really hope to see your vote and your participation in the discussions on
the Boost mailing lists!

---------------------------------------------------

About the library:

The Phoenix library enables FP techniques such as higher order functions,
lambda (unnamed functions), currying (partial function
application) and lazy evaluation in C++. The focus is more on usefulness and
practicality than purity, elegance and strict adherence to FP principles.

History: Phoenix is a mature library from years of use as a sub-project
under Spirit where it serves its purpose for semantic action handling.
Phoenix predates Lambda's acceptance into Boost, but not Lambda itself. When
Lambda was reviewed, it was concluded that both libraries were to be merged,
and work on it began, culminating in Phoenix V2, what you are seeing now (an
interesting offshoot of this effort is Boost.Fusion. We needed a powerful
tuple facility with algorithms to get the design right). Recently, Eric
Niebler did a (fully compatible) port to proto making use of boost.typeof
for result type deduction. Eric's port, while significant, will not be the
subject of the review, but can be regarded as the future of Phoenix (Phoenix
V3).

Phoenix V2 is currently a utility library included with Spirit V2 and
therefore is already available from the latest Boost distributions (headers:
(Continue reading)

Permalink | Reply |
headers
Mathias Gaunard | 22 Sep 14:20

Re: [Review] Phoenix review starts today, September 21st

Hartmut Kaiser wrote:

> The review of Joel de Guzmans and Dan Marsdens Phoenix V2 library starts
> today, September 21st 2008, and will end on September 30th. 
> I really hope to see your vote and your participation in the discussions on
> the Boost mailing lists!

Just a question, why review v2 and not v3, which addresses some of v2 
issues like non-standard type deduction protocol?
It also should have a clearer implementation, even if it may not be as 
efficient.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Joel de Guzman | 22 Sep 16:08

Re: [Review] Phoenix review starts today, September 21st

Mathias Gaunard wrote:
> Hartmut Kaiser wrote:
> 
>> The review of Joel de Guzmans and Dan Marsdens Phoenix V2 library starts
>> today, September 21st 2008, and will end on September 30th. I really 
>> hope to see your vote and your participation in the discussions on
>> the Boost mailing lists!
> 
> Just a question, why review v2 and not v3, which addresses some of v2 
> issues like non-standard type deduction protocol?

Because it's not ready yet V3 is in alpha. V2 OTOH had years of
deployment behind it. It's already in extensive use, not just
within the Spirit community. I could have easily "fixed" the
non-standard type deduction protocol in V2 but decided that
breaking the interface should be done with care starting with v3.
We value backward compatibility.

> It also should have a clearer implementation, even if it may not be as 
> efficient.

clearer implementation? What makes you think so? Because of proto?
I don't agree. You can write very clear code with or without proto.

Regards,
--

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

Permalink | Reply |
headers
Eric Niebler | 22 Sep 19:18

Re: [Review] Phoenix review starts today, September 21st

Joel de Guzman wrote:
> Mathias Gaunard wrote:
>> Hartmut Kaiser wrote:
>>
>>> The review of Joel de Guzmans and Dan Marsdens Phoenix V2 library starts
>>> today, September 21st 2008, and will end on September 30th. I really 
>>> hope to see your vote and your participation in the discussions on
>>> the Boost mailing lists!
>>
>> Just a question, why review v2 and not v3, which addresses some of v2 
>> issues like non-standard type deduction protocol?
> 
> Because it's not ready yet V3 is in alpha. V2 OTOH had years of
> deployment behind it. It's already in extensive use, not just
> within the Spirit community. I could have easily "fixed" the
> non-standard type deduction protocol in V2 but decided that
> breaking the interface should be done with care starting with v3.
> We value backward compatibility.

For those interested, I've zipped up the Phoenix3 alpha and put it here:

http://boost-sandbox.sf.net/libs/phoenix/phoenix3alpha.tar.gz

It builds against trunk. It should also build against the current 
release branch (pre-1.37), but I haven't tested that.

I'd like to stress that this implementation of Phoenix is NOT the 
subject of this review. I'm not putting it in the file vault so as to 
avoid confusion. I'm only providing it for people who would like to play 
with a version of Phoenix built on top of Proto, ResultOf and TypeOf.
(Continue reading)

Permalink | Reply |
headers
Joel de Guzman | 23 Sep 04:18

Re: [Review] Phoenix review starts today, September 21st

Eric Niebler wrote:

> For those interested, I've zipped up the Phoenix3 alpha and put it here:
> 
> http://boost-sandbox.sf.net/libs/phoenix/phoenix3alpha.tar.gz
> 
> It builds against trunk. It should also build against the current 
> release branch (pre-1.37), but I haven't tested that.
> 
> I'd like to stress that this implementation of Phoenix is NOT the 
> subject of this review. I'm not putting it in the file vault so as to 
> avoid confusion. I'm only providing it for people who would like to play 
> with a version of Phoenix built on top of Proto, ResultOf and TypeOf.

Thanks Eric!

>>> It also should have a clearer implementation, even if it may not be 
>>> as efficient.
>>
>> clearer implementation? What makes you think so? Because of proto?
>> I don't agree. You can write very clear code with or without proto.
> 
> Joel has a good point. The v2 implementation of Phoenix is very clean 
> and modular. In fact, the modular design of Phoenix was challenging for 
> Proto, and I'm not yet satisfied with the results. Typically, a DSEL 
> conforms to a grammar that can be stated simply in one place. Phoenix's 
> modularity means that you can include and use only a subset of the 
> library -- a subset that conforms to a simpler grammar. That means that 
> the Phoenix grammar and expression evaluator needs to be distributed, 
> loosely coupled and pluggable. Proto can do this, but it's not pretty.
(Continue reading)

Permalink | Reply |
headers
Mathias Gaunard | 22 Sep 21:01

Re: [Review] Phoenix review starts today, September 21st

Joel de Guzman wrote:

> Because it's not ready yet V3 is in alpha. V2 OTOH had years of
> deployment behind it. It's already in extensive use, not just
> within the Spirit community. I could have easily "fixed" the
> non-standard type deduction protocol in V2 but decided that
> breaking the interface should be done with care starting with v3.
> We value backward compatibility.

Isn't the move to first-class Boost citizen a good opportunity to change 
some parts of the interface, and thus give a new version number?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Joel de Guzman | 23 Sep 03:48

Re: [Review] Phoenix review starts today, September 21st

Mathias Gaunard wrote:
> Joel de Guzman wrote:
> 
>> Because it's not ready yet V3 is in alpha. V2 OTOH had years of
>> deployment behind it. It's already in extensive use, not just
>> within the Spirit community. I could have easily "fixed" the
>> non-standard type deduction protocol in V2 but decided that
>> breaking the interface should be done with care starting with v3.
>> We value backward compatibility.
> 
> Isn't the move to first-class Boost citizen a good opportunity to change 
> some parts of the interface, and thus give a new version number?

Indeed. As noted in the review blurb, V3 will be the future of phoenix.
The V3 interface will be assumed. The most major interface shifts are:

1) ET engine: Use of Boost.Proto
2) Result type deduction: Use of Boost.Typeof
3) Type deduction protocol: Use of Boost.Resultof

As far as the interface goes, we can take all that for granted.
We have the proof of concept.

Then again, it's always a balance. Eric ported to V3 a week after
BoostCon 08, spurred by our discussions at the conference stemming
from his port of lambda. IMO, it's too young to be subject to a
review. We'll need more time to polish it, test it on existing
code, provide backward compatibility to V2, revise the docs to
reflect the changes, etc. V2 OTOH, is already being used in
production code and has years of maturity behind it.
(Continue reading)

Permalink | Reply |
headers
Joel de Guzman | 22 Sep 16:29

Re: [Review] Phoenix review starts today, September 21st

Hi y'all,

As you all know, this is where Phoenix was born. It was 2001.
We needed a sub library to ease handling semantic actions.
If anyone here remembers, it was called SE at first; short
for "Semantic Expressions". Later, it was renamed Phoenix.
Man, how time flies.

May I politely urge you folks here, especially those who have
already been using phoenix, as a Spirit library, or as a stand
alone library, to join in the Boost discussions in the coming
days. I would really love to see phoenix come out from its
shell, as a full fledged boost library.

Hartmut Kaiser wrote:
> Hi all,
> 
> The review of Joel de Guzmans and Dan Marsdens Phoenix V2 library starts
> today, September 21st 2008, and will end on September 30th. 
> I really hope to see your vote and your participation in the discussions on
> the Boost mailing lists!
> 
> ---------------------------------------------------
> 
> About the library:
> 
> The Phoenix library enables FP techniques such as higher order functions,
> lambda (unnamed functions), currying (partial function
> application) and lazy evaluation in C++. The focus is more on usefulness and
> practicality than purity, elegance and strict adherence to FP principles.
(Continue reading)

Permalink | Reply |
headers
Loïc Joly | 22 Sep 20:29

Re: [Review] Phoenix review starts today, September 21st

Hartmut Kaiser a écrit :
> Hi all,
>
> The review of Joel de Guzmans and Dan Marsdens Phoenix V2 library starts
> today, September 21st 2008, and will end on September 30th. 
> I really hope to see your vote and your participation in the discussions on
> the Boost mailing lists!
Some questions that a very quick look at the doc did not answer (please 
point me to the right place if such a place exists):

- If this library is accepted, will that make other boost libraries 
deprecated? (from the introduction, I'm thinking of function, lambda and 
bind, maybe some others?)

- How does this library position itself wrt the upcomming C++0x 
standard, with native support for lambdas, and standardized support for 
function or bind? Is it more expressive?

--

-- 
Loïc

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Mathias Gaunard | 22 Sep 21:03

Re: [Review] Phoenix review starts today, September 21st

Loïc Joly wrote:

> - How does this library position itself wrt the upcomming C++0x 
> standard, with native support for lambdas, and standardized support for 
> function or bind? Is it more expressive?

The C++0x standard only specifies monomorphic lambdas at the moment.
So Phoenix is indeed more expressive, since all expressions are polymorphic.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Peter Dimov | 22 Sep 21:11

Re: [Review] Phoenix review starts today, September 21st

Mathias Gaunard:
> Loïc Joly wrote:
>
> > - How does this library position itself wrt the upcomming C++0x 
> > standard, with native support for lambdas, and standardized support for 
> > function or bind? Is it more expressive?
>
> The C++0x standard only specifies monomorphic lambdas at the moment.
> So Phoenix is indeed more expressive, since all expressions are 
> polymorphic.

Except phoenix::bind, which is monomorphic, for whatever reasons. :-)

http://www.boost.org/doc/libs/1_36_0/libs/spirit/phoenix/doc/html/phoenix/composite.html#phoenix.composite.bind

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
David Abrahams | 22 Sep 22:00
Favicon
Gravatar

Re: [Review] Phoenix review starts today, September 21st


on Mon Sep 22 2008, "Peter Dimov" <pdimov-AT-pdimov.com> wrote:

> Mathias Gaunard:
>> Loïc Joly wrote:
>>
>> > - How does this library position itself wrt the upcomming C++0x > standard,
>> with native support for lambdas, and standardized support for > function or
>> bind? Is it more expressive?
>>
>> The C++0x standard only specifies monomorphic lambdas at the moment.
>> So Phoenix is indeed more expressive, since all expressions are polymorphic.
>
> Except phoenix::bind, which is monomorphic, for whatever reasons. :-)
>
> http://www.boost.org/doc/libs/1_36_0/libs/spirit/phoenix/doc/html/phoenix/composite.html#phoenix.composite.bind

Hmm, that seems like it will needlessly restrict generic code.

--

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Joel de Guzman | 23 Sep 03:13

Re: [Review] Phoenix review starts today, September 21st

David Abrahams wrote:
> on Mon Sep 22 2008, "Peter Dimov" <pdimov-AT-pdimov.com> wrote:
> 
>> Mathias Gaunard:
>>> Loïc Joly wrote:
>>>
>>>> - How does this library position itself wrt the upcomming C++0x > standard,
>>> with native support for lambdas, and standardized support for > function or
>>> bind? Is it more expressive?
>>>
>>> The C++0x standard only specifies monomorphic lambdas at the moment.
>>> So Phoenix is indeed more expressive, since all expressions are polymorphic.
>> Except phoenix::bind, which is monomorphic, for whatever reasons. :-)
>>
>> http://www.boost.org/doc/libs/1_36_0/libs/spirit/phoenix/doc/html/phoenix/composite.html#phoenix.composite.bind
> 
> Hmm, that seems like it will needlessly restrict generic code.

Ah that one. I think that needs clarification. The note is wrong
and should be corrected. A bound function pointer or member function
pointer is only monorphic once bound (of course -- a single function
pointer or member function pointer is monomorphic). The same is true
with bind and lambda bind.

Phoenix bind, like bind and lambda bind is polymorphic at the call
site in the sense that it can bind to any function and function
pointer and function object (which can be polymorphic). One problem
I notice now with the bind documentation of phoenix is that it
lacks the function object binding part.
(Continue reading)

Permalink | Reply |
headers
David Abrahams | 23 Sep 03:49
Favicon
Gravatar

Re: [Review] Phoenix review starts today, September 21st


on Mon Sep 22 2008, Joel de Guzman <joel-AT-boost-consulting.com> wrote:

> David Abrahams wrote:
>> on Mon Sep 22 2008, "Peter Dimov" <pdimov-AT-pdimov.com> wrote:
>>
>>> Mathias Gaunard:
>>>> Loïc Joly wrote:
>>>>
>>>>> - How does this library position itself wrt the upcomming C++0x > standard,
>>>> with native support for lambdas, and standardized support for > function or
>>>> bind? Is it more expressive?
>>>>
>>>> The C++0x standard only specifies monomorphic lambdas at the moment.
>>>> So Phoenix is indeed more expressive, since all expressions are polymorphic.
>>> Except phoenix::bind, which is monomorphic, for whatever reasons. :-)
>>>
>>>
> http://www.boost.org/doc/libs/1_36_0/libs/spirit/phoenix/doc/html/phoenix/composite.html#phoenix.composite.bind>
>> Hmm, that seems like it will needlessly restrict generic code.
>
> Ah that one. I think that needs clarification. The note is wrong
> and should be corrected. A bound function pointer or member function
> pointer is only monorphic once bound (of course -- a single function
> pointer or member function pointer is monomorphic). The same is true
> with bind and lambda bind.

Yeah, but what about a bound polymorphic function object?  The doc makes
it sound like passing through bind removes that polymorphism.
(Continue reading)

Permalink | Reply |
headers
Joel de Guzman | 23 Sep 03:59

Re: [Review] Phoenix review starts today, September 21st

David Abrahams wrote:
> on Mon Sep 22 2008, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
> 
>> David Abrahams wrote:
>>> on Mon Sep 22 2008, "Peter Dimov" <pdimov-AT-pdimov.com> wrote:
>>>
>>>> Mathias Gaunard:
>>>>> Loïc Joly wrote:
>>>>>
>>>>>> - How does this library position itself wrt the upcomming C++0x > standard,
>>>>> with native support for lambdas, and standardized support for > function or
>>>>> bind? Is it more expressive?
>>>>>
>>>>> The C++0x standard only specifies monomorphic lambdas at the moment.
>>>>> So Phoenix is indeed more expressive, since all expressions are polymorphic.
>>>> Except phoenix::bind, which is monomorphic, for whatever reasons. :-)
>>>>
>>>>
>> http://www.boost.org/doc/libs/1_36_0/libs/spirit/phoenix/doc/html/phoenix/composite.html#phoenix.composite.bind>
>>> Hmm, that seems like it will needlessly restrict generic code.
>> Ah that one. I think that needs clarification. The note is wrong
>> and should be corrected. A bound function pointer or member function
>> pointer is only monorphic once bound (of course -- a single function
>> pointer or member function pointer is monomorphic). The same is true
>> with bind and lambda bind.
> 
> Yeah, but what about a bound polymorphic function object?  The doc makes
> it sound like passing through bind removes that polymorphism.
> 
>> Phoenix bind, like bind and lambda bind is polymorphic at the call
(Continue reading)

Permalink | Reply |
headers
Joel de Guzman | 23 Sep 05:14

Re: [Review] Phoenix review starts today, September 21st

Loïc Joly wrote:
> Hartmut Kaiser a écrit :
>> Hi all,
>>
>> The review of Joel de Guzmans and Dan Marsdens Phoenix V2 library starts
>> today, September 21st 2008, and will end on September 30th. I really 
>> hope to see your vote and your participation in the discussions on
>> the Boost mailing lists!
> Some questions that a very quick look at the doc did not answer (please 
> point me to the right place if such a place exists):
> 
> - If this library is accepted, will that make other boost libraries 
> deprecated? (from the introduction, I'm thinking of function, lambda and 
> bind, maybe some others?)

boost.function:

    No. phoenix has no such facility. Don't confuse
    with phoenix.function.

boost.bind:

    No. bind has its place. It's light(er) and is sufficient
    for many tasks. At the very least we should work towards a unification
    of the placeholders and interoperability.

boost.lambda:

    Depends. The original plan was for a Lambda/Phoenix merger
    with Phoenix2 as the basis. Eseentially, it is possible for Phoenix2(3)
(Continue reading)

Permalink | Reply |
headers
dan marsden | 23 Sep 08:51

Re: [Review] Phoenix review starts today, September 21st

Joel de Guzman wrote:
>Mathias Gaunard wrote:
>> Joel de Guzman wrote:
>> Isn't the move to first-class Boost citizen a good opportunity to change
>> some parts of the interface, and thus give a new version number?
>
>Indeed. As noted in the review blurb, V3 will be the future of phoenix.
>The V3 interface will be assumed. The most major interface shifts are:
>
>1) ET engine: Use of Boost.Proto
>2) Result type deduction: Use of Boost.Typeof
>3) Type deduction protocol: Use of Boost.Resultof
>
>As far as the interface goes, we can take all that for granted.
>We have the proof of concept.
>

I think I'd add to your list of major interface shifts:
4) Extension protocol: The current extension approach is tightly coupled
to the hand rolled expression templates, and will need changing for a
proto based v3, unless if I've missed yet more genius from Eric?

Cheers

Dan

      
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply |
headers
Eric Niebler | 23 Sep 17:58

Re: [Review] Phoenix review starts today, September 21st

dan marsden wrote:
> Joel de Guzman wrote:
>> Mathias Gaunard wrote:
>>> Joel de Guzman wrote:
>>> Isn't the move to first-class Boost citizen a good opportunity to change
>>> some parts of the interface, and thus give a new version number?
>> Indeed. As noted in the review blurb, V3 will be the future of phoenix.
>> The V3 interface will be assumed. The most major interface shifts are:
>>
>> 1) ET engine: Use of Boost.Proto
>> 2) Result type deduction: Use of Boost.Typeof
>> 3) Type deduction protocol: Use of Boost.Resultof
>>
>> As far as the interface goes, we can take all that for granted.
>> We have the proof of concept.
> 
> I think I'd add to your list of major interface shifts:
> 4) Extension protocol: The current extension approach is tightly coupled
> to the hand rolled expression templates, and will need changing for a
> proto based v3, unless if I've missed yet more genius from Eric?

I'm not that smart. ;-) I haven't yet thought about v3's extension 
protocol. Extending Phoenix may require some Proto hacking, but it's 
possible that Phoenix could provide a high-level extension interface 
that hooks Proto behind the scenes. Not sure yet.

--

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
(Continue reading)

Permalink | Reply |
headers
Paul A Bristow | 25 Sep 18:35

Re: [Review] Phoenix review starts today, September 21st

>-----Original Message-----
>From: boost-bounces <at> lists.boost.org 
>[mailto:boost-bounces <at> lists.boost.org] On Behalf Of Hartmut Kaiser
>Sent: 22 September 2008 00:58
>To: boost <at> lists.boost.org; boost-users <at> lists.boost.org; 
>boost-announce <at> lists.boost.org
>Cc: 'Spirit General Mailing List'
>Subject: [boost] [Review] Phoenix review starts today, September 21st
>The review of Joel de Guzmans and Dan Marsdens Phoenix V2 
>library starts
>today, September 21st 2008,

>Phoenix V2 is a very important infrastructure library, IHMO. 
>It has been
>used for several other library writing efforts already, most notably, Spirit V2.
>
>Please always state in your review, whether you think the 
>library should be accepted as a Boost library!

I vote for acceptance.

>Additionally please consider giving feedback on the following general
>topics:

>- What is your evaluation of the design?

Seems a pity we need languages within languages within languages, but there you go :-(

It clearly "does what it says on the tin".
(Continue reading)

Permalink | Reply |
headers
Joel de Guzman | 26 Sep 03:36

Re: [Review] Phoenix review starts today, September 21st

Paul A Bristow wrote:

>> Please always state in your review, whether you think the 
>> library should be accepted as a Boost library!
> 
> I vote for acceptance.

Thank you!

>> Additionally please consider giving feedback on the following general
>> topics:
> 
>> - What is your evaluation of the design?
> 
> Seems a pity we need languages within languages within languages, but there you go :-(

One that emulates C++ in C++ even! :P Can another language do that?

> It clearly "does what it says on the tin".
> 
>> - What is your evaluation of the documentation?
> 
> Reads very nicely, with remarkably few typos (a few I noted attached).

Will appply. Thanks!

[snips ...]

> One further comment.
>
(Continue reading)

Permalink | Reply |
headers
Daniel Walker | 27 Sep 01:20

Re: [Review] Phoenix review starts today, September 21st

On Sun, Sep 21, 2008 at 7:58 PM, Hartmut Kaiser
<hartmut.kaiser <at> gmail.com> wrote:
> Hi all,
>
> The review of Joel de Guzmans and Dan Marsdens Phoenix V2 library starts
> today, September 21st 2008, and will end on September 30th.
> I really hope to see your vote and your participation in the discussions on
> the Boost mailing lists!
>
> ---------------------------------------------------

Of course, it's hard to be subjective reviewing Phoenix, since I'm
already a fan, but I'm going to try to approach this as I would any
library and pretend like I don't know who the authors are. My review
of Phoenix follows.

I think Phoenix version 2 should be rejected as a Boost library.
Instead, we should focus on version 3, i.e. Phoenix3/Lambda2.

Obviously, there's nothing "wrong" with the Phoenix2 design,
implementation, documentation, etc. However, I believe Boost users
don't appreciably gain anything from a release of version 2 as a
top-level Boost library, and I believe a premature release could
actually come at a cost to Boost users as well as Boost developers.

Accepting Phoenix2 as a Boost library is essentially just a rebranding
of the current library included with Boost.Spirit. I don't see how
users benefit from that rebranding. Potentially, the rebranding could
deteriorate user experience, since Phoenix2 addresses the same problem
domain as other Boost libraries and uses similar names (bind,
(Continue reading)

Permalink | Reply |
headers
David Abrahams | 27 Sep 01:48
Favicon
Gravatar

Re: [Review] Phoenix review starts today, September 21st


on Fri Sep 26 2008, "Daniel Walker" <daniel.j.walker-AT-gmail.com> wrote:

> On Sun, Sep 21, 2008 at 7:58 PM, Hartmut Kaiser
> <hartmut.kaiser <at> gmail.com> wrote:
>> Hi all,
>>
>> The review of Joel de Guzmans and Dan Marsdens Phoenix V2 library starts
>> today, September 21st 2008, and will end on September 30th.
>> I really hope to see your vote and your participation in the discussions on
>> the Boost mailing lists!
>>
>> ---------------------------------------------------
>
> Of course, it's hard to be subjective reviewing Phoenix, since I'm
> already a fan, but I'm going to try to approach this as I would any
> library and pretend like I don't know who the authors are. My review
> of Phoenix follows.

Wow, that was a very thoughtfully written review and I look forward to
hearing the response.  Your arguments are very persuasive, and highlight
some of the concerns I've had since learning that the next version of
Phoenix is (nearly ready and?) due to be incompatible with this one.

--

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply |
headers
Joel de Guzman | 27 Sep 05:44

Re: [Review] Phoenix review starts today, September 21st

Daniel Walker wrote:

 > Of course, it's hard to be subjective reviewing Phoenix, since I'm
 > already a fan, but I'm going to try to approach this as I would any
 > library and pretend like I don't know who the authors are. My review
 > of Phoenix follows.

Thank you for your review.

 > I think Phoenix version 2 should be rejected as a Boost library.
 > Instead, we should focus on version 3, i.e. Phoenix3/Lambda2.

I understand your concerns.

Will you change your vote if I say that Phoenix2 will not be
repackaged into Boost? The real intent is to have Phoenix3/Lambda2
into Boost, not Phoenix2. I asked for a review to flesh out
the few remaining issues and to achieve the goal of having a
top-notch library. All the major issues raised thus far are
interface related. These can be implemented in a short period
of time in Phoenix. They are not major issues in terms of
implementation. Phoenix3 is the proof. Fusion is also a proof.
Fusion started out without Typeof and Result_of support. Soon
thereafter, these were added.

Perhaps it was premature to ask for a review, but if you look
closely into the Proto port, Phoenix3 *is* Phoenix2 targetting a
different back-end (proto, instead of hand-coded). It's not a
total rewrite, like say, Spirit2 from Spirit1 or Phoenix2 from
Phoenix1.
(Continue reading)

Permalink | Reply |
headers
Robert Jones | 27 Sep 12:31

Re: [Review] Phoenix review starts today, September 21st

On Sat, Sep 27, 2008 at 4:44 AM, Joel de Guzman
<joel <at> boost-consulting.com> wrote:
> Daniel Walker wrote:
> <snip>

To echo David - wow, that was some review from Daniel!

In response to Joel - Some of your purpose in requesting a review
now is certainly being served for me. The discussion provoked is
proving hugely useful and informative, not least because the history
of Phoenix apparently goes back a long way, and certainly far
beyond the point when I started paying attention.

So, as a user who is moderately familiar with BLL, but very new
to Phoenix, it would seem there is very little merit in investing too
much effort becoming familiar with Phoenix, until V3 arrives. A logic
that presumably applies to any new user.

As a result of reading Daniel's review my appreciation of the overall
'roadmap' has increased significantly.

Daniel's review also mentioned a 'chatty', scene setting introductory
chapter that used to part of the documentation. I too would like to this
restored to the documentation.

Thank you Daniel for such an informative review.

- Rob.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply |
headers
Joel de Guzman | 27 Sep 13:39

Re: [Review] Phoenix review starts today, September 21st

Robert Jones wrote:
> On Sat, Sep 27, 2008 at 4:44 AM, Joel de Guzman
> <joel <at> boost-consulting.com> wrote:
>> Daniel Walker wrote:
>> <snip>
> 
> To echo David - wow, that was some review from Daniel!
> 
> In response to Joel - Some of your purpose in requesting a review
> now is certainly being served for me. The discussion provoked is
> proving hugely useful and informative, not least because the history
> of Phoenix apparently goes back a long way, and certainly far
> beyond the point when I started paying attention.
> 
> So, as a user who is moderately familiar with BLL, but very new
> to Phoenix, it would seem there is very little merit in investing too
> much effort becoming familiar with Phoenix, until V3 arrives. A logic
> that presumably applies to any new user.

I would urge you otherwise. I did a quick scan of the Phoenix2 docs.
I can safely say that the majority of the interface will remain as-is.
Most of the changes will be transparent for the user (for instance
the use of boost.typeof and boost.result_of will not affect most code).
Neither will the use of a common set of placeholders. There are only
two parts in the docs where there will be changes to the interface:
the Phoenix function and some parts of the extension mechanism. The
first is cosmetic.

Really, such interface changes are a normal part of transitioning
from pre-review to post-review. All libraries assimilated into boost
(Continue reading)

Permalink | Reply |
headers
David Abrahams | 27 Sep 19:48
Favicon
Gravatar

Re: [Review] Phoenix review starts today, September 21st


on Sat Sep 27 2008, Joel de Guzman <joel-AT-boost-consulting.com> wrote:

> Please, let's not throw out the baby with the bathwater.

Just to be clear, by praising Daniel's review I was not trying to make
some kind of weak vote for rejection.  Daniel raised some concerns that
I also had, but didn't have the time or presence of mind to articulate,
and I am very happy with what Joel has written in response so far.

--

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Daniel Walker | 28 Sep 00:14

Re: [Review] Phoenix review starts today, September 21st

On Sat, Sep 27, 2008 at 7:39 AM, Joel de Guzman
<joel <at> boost-consulting.com> wrote:
> While I understand and appreciate the comments raised thus far, I say
> that the review grossly magnifies these aspects while underrating
> the remaining 95% of the library. If you look at: http://tinyurl.com/4y47z7,
> Values, References, Arguments, Composites, Lazy Operators, Lazy Statements
> Construct, New, Delete, Casts, Operator, Statement, Object, Scope,
> Bind will remain as-is. Only Lazy Functions and Inside Phoenix (the
> extension
> mechanism) will have some changes.
>
> Please, let's not throw out the baby with the bathwater.

OK, regarding babies in bathwater... :-) Again, throwing Phoenix out
of Boost is not the question. All of the existing functionality is
currently distributed with Boost.Spirit and will remain so. The issue
is where to go next.

I don't want to try to parse what's changed between Phoenix2 and
Phoenix3, but it's important to identify what's being reviewed. So,
just to get a since of the difference, I ran diff -qr on the two
versions and found that of 108 files 43 have been removed and 65
modified. To try to get a sense of the impact of the new Proto
backend, I ran grep -rle 'proto::' on Phoenix3 and found that of 66
files 27 matched, including bind.hpp.

We're not undervaluing Phoenix2; no one is tossing out babies, it will
remain in Boost.Spirit. We also shouldn't undervalue the changes that
bring us to Phoenix3. So, even though they may seem trivial if you are
familiar with the code, the changes between Phoenix2 and Phoenix3 are
(Continue reading)

Permalink | Reply |
headers
Joel de Guzman | 28 Sep 02:25

Re: [Review] Phoenix review starts today, September 21st

Daniel Walker wrote:
> On Sat, Sep 27, 2008 at 7:39 AM, Joel de Guzman
> <joel <at> boost-consulting.com> wrote:
>> While I understand and appreciate the comments raised thus far, I say
>> that the review grossly magnifies these aspects while underrating
>> the remaining 95% of the library. If you look at: http://tinyurl.com/4y47z7,
>> Values, References, Arguments, Composites, Lazy Operators, Lazy Statements
>> Construct, New, Delete, Casts, Operator, Statement, Object, Scope,
>> Bind will remain as-is. Only Lazy Functions and Inside Phoenix (the
>> extension
>> mechanism) will have some changes.
>>
>> Please, let's not throw out the baby with the bathwater.
> 
> OK, regarding babies in bathwater... :-) Again, throwing Phoenix out
> of Boost is not the question. All of the existing functionality is
> currently distributed with Boost.Spirit and will remain so. The issue
> is where to go next.
> 
> I don't want to try to parse what's changed between Phoenix2 and
> Phoenix3, but it's important to identify what's being reviewed. So,
> just to get a since of the difference, I ran diff -qr on the two
> versions and found that of 108 files 43 have been removed and 65
> modified. To try to get a sense of the impact of the new Proto
> backend, I ran grep -rle 'proto::' on Phoenix3 and found that of 66
> files 27 matched, including bind.hpp.

I'm sure most folks here will agree that diffing and grepping files
do not do justice in assessing the difference from one revision
to the next. Only an in-depth perusal will reveal that the structure
(Continue reading)

Permalink | Reply |
headers
Daniel Walker | 28 Sep 03:32

Re: [Review] Phoenix review starts today, September 21st

On Sat, Sep 27, 2008 at 8:25 PM, Joel de Guzman
<joel <at> boost-consulting.com> wrote:
> Daniel Walker wrote:
>>
>> On Sat, Sep 27, 2008 at 7:39 AM, Joel de Guzman
>> <joel <at> boost-consulting.com> wrote:
>>>
>>> While I understand and appreciate the comments raised thus far, I say
>>> that the review grossly magnifies these aspects while underrating
>>> the remaining 95% of the library. If you look at:
>>> http://tinyurl.com/4y47z7,
>>> Values, References, Arguments, Composites, Lazy Operators, Lazy
>>> Statements
>>> Construct, New, Delete, Casts, Operator, Statement, Object, Scope,
>>> Bind will remain as-is. Only Lazy Functions and Inside Phoenix (the
>>> extension
>>> mechanism) will have some changes.
>>>
>>> Please, let's not throw out the baby with the bathwater.
>>
>> OK, regarding babies in bathwater... :-) Again, throwing Phoenix out
>> of Boost is not the question. All of the existing functionality is
>> currently distributed with Boost.Spirit and will remain so. The issue
>> is where to go next.
>>
>> I don't want to try to parse what's changed between Phoenix2 and
>> Phoenix3, but it's important to identify what's being reviewed. So,
>> just to get a since of the difference, I ran diff -qr on the two
>> versions and found that of 108 files 43 have been removed and 65
>> modified. To try to get a sense of the impact of the new Proto
(Continue reading)

Permalink | Reply |
headers
Joel de Guzman | 28 Sep 03:53

Re: [Review] Phoenix review starts today, September 21st

Daniel Walker wrote:
> On Sat, Sep 27, 2008 at 8:25 PM, Joel de Guzman
> <joel <at> boost-consulting.com> wrote:
>> Daniel Walker wrote:
>>> On Sat, Sep 27, 2008 at 7:39 AM, Joel de Guzman
>>> <joel <at> boost-consulting.com> wrote:
>>>> While I understand and appreciate the comments raised thus far, I say
>>>> that the review grossly magnifies these aspects while underrating
>>>> the remaining 95% of the library. If you look at:
>>>> http://tinyurl.com/4y47z7,
>>>> Values, References, Arguments, Composites, Lazy Operators, Lazy
>>>> Statements
>>>> Construct, New, Delete, Casts, Operator, Statement, Object, Scope,
>>>> Bind will remain as-is. Only Lazy Functions and Inside Phoenix (the
>>>> extension
>>>> mechanism) will have some changes.
>>>>
>>>> Please, let's not throw out the baby with the bathwater.
>>> OK, regarding babies in bathwater... :-) Again, throwing Phoenix out
>>> of Boost is not the question. All of the existing functionality is
>>> currently distributed with Boost.Spirit and will remain so. The issue
>>> is where to go next.
>>>
>>> I don't want to try to parse what's changed between Phoenix2 and
>>> Phoenix3, but it's important to identify what's being reviewed. So,
>>> just to get a since of the difference, I ran diff -qr on the two
>>> versions and found that of 108 files 43 have been removed and 65
>>> modified. To try to get a sense of the impact of the new Proto
>>> backend, I ran grep -rle 'proto::' on Phoenix3 and found that of 66
>>> files 27 matched, including bind.hpp.
(Continue reading)

Permalink | Reply |
headers
Daniel Walker | 28 Sep 04:31

Re: [Review] Phoenix review starts today, September 21st

On Sat, Sep 27, 2008 at 9:53 PM, Joel de Guzman
<joel <at> boost-consulting.com> wrote:
> Daniel Walker wrote:
>>
>> On Sat, Sep 27, 2008 at 8:25 PM, Joel de Guzman
>> <joel <at> boost-consulting.com> wrote:
>>>
>>> Daniel Walker wrote:
>>>>
>>>> On Sat, Sep 27, 2008 at 7:39 AM, Joel de Guzman
>>>> <joel <at> boost-consulting.com> wrote:
>>>>>
>>>>> While I understand and appreciate the comments raised thus far, I say
>>>>> that the review grossly magnifies these aspects while underrating
>>>>> the remaining 95% of the library. If you look at:
>>>>> http://tinyurl.com/4y47z7,
>>>>> Values, References, Arguments, Composites, Lazy Operators, Lazy
>>>>> Statements
>>>>> Construct, New, Delete, Casts, Operator, Statement, Object, Scope,
>>>>> Bind will remain as-is. Only Lazy Functions and Inside Phoenix (the
>>>>> extension
>>>>> mechanism) will have some changes.
>>>>>
>>>>> Please, let's not throw out the baby with the bathwater.
>>>>
>>>> OK, regarding babies in bathwater... :-) Again, throwing Phoenix out
>>>> of Boost is not the question. All of the existing functionality is
>>>> currently distributed with Boost.Spirit and will remain so. The issue
>>>> is where to go next.
>>>>
(Continue reading)

Permalink | Reply |
headers
Robert Jones | 27 Sep 21:39

Re: [Review] Phoenix review starts today, September 21st

On Sat, Sep 27, 2008 at 11:31 AM, Robert Jones <robertgbjones <at> gmail.com> wrote:
> On Sat, Sep 27, 2008 at 4:44 AM, Joel de Guzman
> <joel <at> boost-consulting.com> wrote:
>> Daniel Walker wrote:
>> <snip>
>
> To echo David - wow, that was some review from Daniel!
>

I should perhaps have been clear - my vote to accept Phoenix still stands.

There's just too much good stuff in it to turn it down!

- Rob.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Daniel Walker | 27 Sep 23:21

Re: [Review] Phoenix review starts today, September 21st

On Sat, Sep 27, 2008 at 3:39 PM, Robert Jones <robertgbjones <at> gmail.com> wrote:
> On Sat, Sep 27, 2008 at 11:31 AM, Robert Jones <robertgbjones <at> gmail.com> wrote:
>> On Sat, Sep 27, 2008 at 4:44 AM, Joel de Guzman
>> <joel <at> boost-consulting.com> wrote:
>>> Daniel Walker wrote:
>>> <snip>
>>
>> To echo David - wow, that was some review from Daniel!
>>
>
> I should perhaps have been clear - my vote to accept Phoenix still stands.
>
> There's just too much good stuff in it to turn it down!

Thanks for the pats-on-the-back! And of course, I'm not lobbying to
change anyone's vote. There are lots of valid reasons to vote for
acceptance.

Also, just to clarify, none of the good stuff in Phoenix2 will be
turned down as a result of this review. Phoenix is currently
distributed with Boost.Spirit and that should definitely remain the
case. So, voting no does not mean removing Phoenix from Boost.

What's at issue is whether/how Phoenix should be distributed as a
top-level, Boost-reviewed library. IMHO, I think Phoenix should be
distributed as a major upgrade of Boost.Lambda. Voting yes, as far as
I can tell, means distributing Phoenix2 as it's own top-level library
- Boost.Phoenix - at least for some period of time, which I don't
agree with. But then perhaps there is some confusion as to what
exactly is being reviewed.
(Continue reading)

Permalink | Reply |
headers
Mathias Gaunard | 27 Sep 14:42

Re: [Review] Phoenix review starts today, September 21st

Joel de Guzman wrote:

> And, not to be forgotten, there's also the Lambda Phoenix
> relationship. I personally would not want to have Phoenix2
> as-is into Boost without providing a strategy for a painless
> transition for old Lambda into the new. The review is a good
> opportunity for all these matters to be discussed.

I suppose adding support for the sig template in boost::result_of would 
surely be of use.
I remember a technique to detect template members was discussed, so it 
ought to be possible.

Also, when using decltype or emulation, there should be no problem, 
since the return type deduction technique isn't used at all.

On a related note, I think compatibility with the result_type protocol 
is also very important, since it is still what the standard library 
uses. (I don't know if it's ever planned that it will use result_of 
instead, but for the moment my standard library -- latest GCC -- 
requires result_type on its function objects fairly often).
So as I said in another thread, phoenix should try to provide 
result_type whenever possible. A simple make_monorphic<T1, ..., Tn>(f) 
helper could also be useful (it would simply invocate result_of with the 
template arguments to generate the result_type).

Also, monomorphic function objects should be able to lead to even 
clearer error messages, so it could be interesting from that point of 
view too.
Ideally, it would be nice if the signatures of the generated objects
(Continue reading)

Permalink | Reply |
headers
Joel de Guzman | 27 Sep 15:27

Re: [Review] Phoenix review starts today, September 21st

Mathias Gaunard wrote:
> Joel de Guzman wrote:
> 
>> And, not to be forgotten, there's also the Lambda Phoenix
>> relationship. I personally would not want to have Phoenix2
>> as-is into Boost without providing a strategy for a painless
>> transition for old Lambda into the new. The review is a good
>> opportunity for all these matters to be discussed.
> 
> I suppose adding support for the sig template in boost::result_of would 
> surely be of use.
> I remember a technique to detect template members was discussed, so it 
> ought to be possible.
> 
> Also, when using decltype or emulation, there should be no problem, 
> since the return type deduction technique isn't used at all.
> 
> On a related note, I think compatibility with the result_type protocol 
> is also very important, since it is still what the standard library 
> uses. (I don't know if it's ever planned that it will use result_of 
> instead, but for the moment my standard library -- latest GCC -- 
> requires result_type on its function objects fairly often).

AFAIR, the old standard library result_type protocol is compatible
with the result_of protocol.

> So as I said in another thread, phoenix should try to provide 
> result_type whenever possible. A simple make_monorphic<T1, ..., Tn>(f) 
> helper could also be useful (it would simply invocate result_of with the 
> template arguments to generate the result_type).
(Continue reading)

Permalink | Reply |
headers
Mathias Gaunard | 27 Sep 19:55

Re: [Review] Phoenix review starts today, September 21st

Joel de Guzman wrote:

> AFAIR, the old standard library result_type protocol is compatible
> with the result_of protocol.

std::result_of<F(the args types)> uses F::result_type if it exists, but 
the other way around is of course not possible, since result_type can 
only work with monomorphic functors.

So if I have a function that expects a functor F that provides 
F::result_type, the fact that the functor provides std::result_of<F(the 
args types)>::type, doesn't really help since it doesn't guarantee 
F::result_type is available.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Daniel Walker | 27 Sep 23:02

Re: [Review] Phoenix review starts today, September 21st

On Fri, Sep 26, 2008 at 11:44 PM, Joel de Guzman
<joel <at> boost-consulting.com> wrote:
> Daniel Walker wrote:
>> I think Phoenix version 2 should be rejected as a Boost library.
>> Instead, we should focus on version 3, i.e. Phoenix3/Lambda2.
>
> I understand your concerns.
>
> Will you change your vote if I say that Phoenix2 will not be
> repackaged into Boost? The real intent is to have Phoenix3/Lambda2
> into Boost, not Phoenix2.

Then let's review Phoenix3/Lambda2. I might vote yes for that library
after I have a chance to review it. I can't vote yes for Phoenix2;
i.e. the library linked to by the review manager at the beginning of
this thread. In other words, I can't accept the library I have
reviewed, not without major changes:

1) The documentation is great for Phoenix2. But it is not the
documentation for Lambda2. It will need to be significantly rewritten.
As I believe you mentioned earlier, the Lambda2 documentation should
probably include a lot of material from the current Boost.Lambda
documentation that folks are familiar with.

2) The implementation needs significant changes to replace the
"backend" with Proto. Apparently, that work is just about complete in
Phoenix3 alpha. So again, why shouldn't we  spend time on the library
implementation we actually intended to distribute? There has been a
conflicting argument put forward in the discussion so far. Phoenix2 is
mature and already distributed, so we can be confident in it's
(Continue reading)

Permalink | Reply |
headers
Jeff Flinn | 29 Sep 14:08
Favicon

Re: [Review] Phoenix review starts today, September 21st

Joel de Guzman wrote:
> Daniel Walker wrote:
>  >> - What is your evaluation of the documentation?
>  >
>  > The documentation is excellent. I mostly looked at the "starter kit,"
>  > which is as good of a quick start guide as any I've seen. However, I
>  > seem to remember that the old documentation had an excellent
>  > introductory chapter that gave a brief overview of FP and touched on
>  > the history of Phoenix. I didn't notice that material in the current
>  > documentation. If it was removed, it should be brought back!
> 
> Hmm. Some people say I'm overly verbose and chatty. I recently
> tend to snip portions of the documentation because of that.
> I'll see what I can do. Thanks for the compliment.

I agree with Daniel, an FP overview would be very useful, especially 
since you already have the info written.

And please do keep up the verbosity. :-) I had always avoided parsing 
projects until I read through your Spirit docs. The background info on 
general parsing gave me what I needed to quickly use spirit, and since 
then I've been looking for any chance to use spirit.

Jeff

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
dan marsden | 28 Sep 10:10

Re: [Review] Phoenix review starts today, September 21st

Daniel Walker wrote:
<snip>
>Of course not. :-) But going in-depth into V2's implementation is not
>the same as going in-depth into V3. The design may be the same, but
>simple diffing and greping shows the implementations are not. And
>that's to be expected. As I understand, whole components were gutted
>and replaced with Proto, which is a good thing. So let's continue that
>effort and spend our energy on V3 and not look back!
>
>Now, how that relates to the review formalities and the fact that
>apparently V2 is under review, I am not sure. As far as I can tell,
>all the reviews thus far have assumed the V2 implementation. I would
>suggest withdrawing V2 from consideration (leaving it as is in
>Boost.Spirit), finishing V3 (which becomes the new Boost.Lambda), and
>then resubmitting for review, but I'm no expert on this process.
>
It is my understanding that Boost authors retain the "rights" to modify and
upgrade their libraries once accepted, both in terms of implementation
and interface changes. Boost.Xpressive has seen many changes iirc,
including the sorts of changes that we're discussing (reimplementing
in terms of proto + I believe some smaller interface changes). Many
other libraries have similar history. If the authors of these libraries
had stated their development plans, in advance of review, should they 
have been rejected until they were "finished"? Joel has been very open
in stating his future plans, but what he plans has happened many times
before to accepted libraries.

Obviously the rather fluid state of the libraries does muddy the purpose
of the review. I'd suggest we review libraries as is, answer all the usual
questions about interface, quality of implementation, docs etc. There seems
(Continue reading)

Permalink | Reply |
headers
David Abrahams | 28 Sep 21:07
Favicon
Gravatar

Re: [Review] Phoenix review starts today, September 21st


on Sun Sep 28 2008, dan marsden <danmarsden-AT-yahoo.co.uk> wrote:

> It is my understanding that Boost authors retain the "rights" to modify and
> upgrade their libraries once accepted, both in terms of implementation
> and interface changes. Boost.Xpressive has seen many changes iirc,
> including the sorts of changes that we're discussing (reimplementing
> in terms of proto + I believe some smaller interface changes). Many
> other libraries have similar history. If the authors of these libraries
> had stated their development plans, in advance of review, should they 
> have been rejected until they were "finished"? Joel has been very open
> in stating his future plans, but what he plans has happened many times
> before to accepted libraries.

I think one difference here may be that Joel already knows he has
interface-breaking changes planned (if that's not actually the case, I
apologize).  Several libraries have had interface-breaking changes after
acceptance, but AFAIK these were not anticipated at the time of the
review.

--

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Joel de Guzman | 29 Sep 03:24

Re: [Review] Phoenix review starts today, September 21st

David Abrahams wrote:
> on Sun Sep 28 2008, dan marsden <danmarsden-AT-yahoo.co.uk> wrote:
> 
>> It is my understanding that Boost authors retain the "rights" to modify and
>> upgrade their libraries once accepted, both in terms of implementation
>> and interface changes. Boost.Xpressive has seen many changes iirc,
>> including the sorts of changes that we're discussing (reimplementing
>> in terms of proto + I believe some smaller interface changes). Many
>> other libraries have similar history. If the authors of these libraries
>> had stated their development plans, in advance of review, should they 
>> have been rejected until they were "finished"? Joel has been very open
>> in stating his future plans, but what he plans has happened many times
>> before to accepted libraries.
> 
> I think one difference here may be that Joel already knows he has
> interface-breaking changes planned (if that's not actually the case, I
> apologize).  Several libraries have had interface-breaking changes after
> acceptance, but AFAIK these were not anticipated at the time of the
> review.

Yes, I do anticipate interface-breaking changes. The proto port (What
we call V3) is special because it actually captures a lot of what I
had in mind for the next revision. I also expect, as typical with
a review, more changes that I haven't foreseen. The suggested "optional-
laziness" and the new and improved switch_ syntax, are two such cases
of high consideration. I thought it would make sense to addess all
these in one step.

Again, let me reiterate, that despite all these changes, the design
and implementation or V2 is still sound, and IMO, pretty much up
(Continue reading)

Permalink | Reply |
headers
David Abrahams | 29 Sep 13:58
Favicon
Gravatar

Re: [Review] Phoenix review starts today, September 21st


on Sun Sep 28 2008, Joel de Guzman <joel-AT-boost-consulting.com> wrote:

>> I think one difference here may be that Joel already knows he has
>> interface-breaking changes planned (if that's not actually the case, I
>> apologize).  Several libraries have had interface-breaking changes after
>> acceptance, but AFAIK these were not anticipated at the time of the
>> review.
>
> Yes, I do anticipate interface-breaking changes. The proto port (What
> we call V3) is special because it actually captures a lot of what I
> had in mind for the next revision. I also expect, as typical with
> a review, more changes that I haven't foreseen. The suggested "optional-
> laziness" and the new and improved switch_ syntax, are two such cases
> of high consideration. I thought it would make sense to addess all
> these in one step.
>
> Again, let me reiterate, that despite all these changes, the design
> and implementation or V2 is still sound, and IMO, pretty much up
> to standards with Boost quality. It is still the solid basis for
> V3 with up to 95% of the interface intact and essentially unchanged
> design and structure.

In case *I* wasn't sufficiently clear about it, let me try to be
painfully explicit: we may want to discuss whether it's good for Boost
or its users if we release a new top-level library and then break its
interface in the next release, three months later.  I'm all for
accepting some version of Phoenix, but I want to make sure that users'
needs for -- and the public perception of -- Boost's stability are
accounted for.
(Continue reading)

Permalink | Reply |
headers
Mika Heiskanen | 29 Sep 14:16
Favicon

Re: [Review] Phoenix review starts today, September 21st

David Abrahams wrote:

> In case *I* wasn't sufficiently clear about it, let me try to be
> painfully explicit: we may want to discuss whether it's good for Boost
> or its users if we release a new top-level library and then break its
> interface in the next release, three months later.  I'm all for
> accepting some version of Phoenix, but I want to make sure that users'
> needs for -- and the public perception of -- Boost's stability are
> accounted for.

Also please note that most major Linux distributions are still back at 1.33 or 1.34. Even if the 
next boost release would be only 3 months away, it may take a long while until the new release makes 
it into any major Linux distribution. It would be quite unfortunate if some distro happened to 
upgrade boost between the two Phoenix releases.

There was an attempt to upgrade to 1.36 in the forthcoming Fedora 10, but API incompatibilities 
caused the idea to be dropped, the schedule was too tight for resolving all the problems. More 
details can be found for example here:

http://www.linux-archive.org/fedora-development/141634-major-boost-breakage.html

--> Mika Heiskanen / FMI
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Joel de Guzman | 29 Sep 15:22

Re: [Review] Phoenix review starts today, September 21st

Mika Heiskanen wrote:
> David Abrahams wrote:
> 
>> In case *I* wasn't sufficiently clear about it, let me try to be
>> painfully explicit: we may want to discuss whether it's good for Boost
>> or its users if we release a new top-level library and then break its
>> interface in the next release, three months later.  I'm all for
>> accepting some version of Phoenix, but I want to make sure that users'
>> needs for -- and the public perception of -- Boost's stability are
>> accounted for.
> 
> Also please note that most major Linux distributions are still back at 
> 1.33 or 1.34. Even if the next boost release would be only 3 months 
> away, it may take a long while until the new release makes it into any 
> major Linux distribution. It would be quite unfortunate if some distro 
> happened to upgrade boost between the two Phoenix releases.

Understood 100%. Such a thing will not happen. There will only be one
release. That release will take into account all that's discussed
in the review.

Regards,
--

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply |
headers
Paul A Bristow | 29 Sep 15:14

Re: [Review] Phoenix review starts today, September 21st


>-----Original Message-----
>From: boost-bounces <at> lists.boost.org 
>[mailto:boost-bounces <at> lists.boost.org] On Behalf Of David Abrahams
>Sent: 29 September 2008 12:59
>To: boost <at> lists.boost.org
>Subject: Re: [boost] [Review] Phoenix review starts today, 
>September 21st

>> Again, let me reiterate, that despite all these changes, the design
>> and implementation or V2 is still sound, and IMO, pretty much up
>> to standards with Boost quality. It is still the solid basis for
>> V3 with up to 95% of the interface intact and essentially unchanged
>> design and structure.
>
>In case *I* wasn't sufficiently clear about it, let me try to be
>painfully explicit: we may want to discuss whether it's good for Boost
>or its users if we release a new top-level library and then break its
>interface in the next release, three months later.  I'm all for
>accepting some version of Phoenix, but I want to make sure that users'
>needs for -- and the public perception of -- Boost's stability are
>accounted for.

I don't see that providing V3 *as well as V2* is breaking anything.

Surely it is quite clear that V2 and V3 are different beasts, and if you want to jump from one to the other, you
risk some trouble.

This is price of improvement : I think Joel's proposed way of managing it is fine.
(Continue reading)

Permalink