headers
Hartmut Kaiser | 8 Apr 00:02
Picon

[Proto] Review result

Hi all,

initially I was hoping to find some time over the last weekend to go through
the reviews in great detail to put together a proper review report. Well, as
things happen, I was not able to find the time :-(

To avoid further delays, here is the short version of the review result:
Proto got 16 reviews (That's well above average! Thanks to all for
participating), out of which 15 have been positive. The one 'No' essentially
stated that the library, even if doubtless very useful, shouldn't be
accepted yet, mainly because there has to be done more work in the area of
formalizing the problem domain.

In my opinion this is an overwhelming result and I'm whole heartily agreeing
with the majority of the voters.

Proto is accepted as a Boost library.

The discussions have been very detailed and there have been raised a lot of
(mostly minor) issues, but Eric is aware of the problems and is working on
solving them. I'll try to put together a summary as soon as possible.

Regards Hartmut
Review Manager

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce
Permalink | Reply |
headers
Eric Niebler | 8 Apr 00:26
Picon

Re: [Proto] Review result

Hartmut Kaiser wrote:
> Hi all,
> 
> initially I was hoping to find some time over the last weekend to go through
> the reviews in great detail to put together a proper review report. Well, as
> things happen, I was not able to find the time :-(
> 
> To avoid further delays, here is the short version of the review result:
> Proto got 16 reviews (That's well above average! Thanks to all for
> participating), out of which 15 have been positive. The one 'No' essentially
> stated that the library, even if doubtless very useful, shouldn't be
> accepted yet, mainly because there has to be done more work in the area of
> formalizing the problem domain.
> 
> In my opinion this is an overwhelming result and I'm whole heartily agreeing
> with the majority of the voters.
> 
> Proto is accepted as a Boost library.
> 
> The discussions have been very detailed and there have been raised a lot of
> (mostly minor) issues, but Eric is aware of the problems and is working on
> solving them. I'll try to put together a summary as soon as possible.

Thanks to everybody who participated in the review, esp. Hartmut for 
being review manager. For anybody interested in following along, 
branches/proto/v4 is where I'm incorporating the review feedback. It 
already has all of the interface breaking changes I plan to make, modulo 
any necessary changes that come out of the "boost::result_of and C++03" 
thread. I'll be trying very hard to get proto into trunk in time for 1.36.
(Continue reading)

Permalink | Reply |
headers
Larry Evans | 15 Apr 18:05

[Proto]Rationale for grammar/transform bundling (was Re: [Proto] Review result

On 04/07/08 17:04, Hartmut Kaiser wrote:
[snip]
> participating), out of which 15 have been positive. The one 'No' essentially
> stated that the library, even if doubtless very useful, shouldn't be
> accepted yet, mainly because there has to be done more work in the area of
> formalizing the problem domain.

There was also an issue with separation of transforms from grammars.
This mixing made it hard for me to understand transforms.  I believe
separating the two would make understanding for other novice users
easier also.  Of course I'm not even real sure that separation is
possible, as I intimated with the '*highly* speculative' qualifier
in my review.  However, since then I've been trying to separate the
two.  This lead me to understand *maybe* why bundling the two is
necessary.  The pass_through transform docs contain:

   , boost::result_of
     < Grammar::proto_childN(Expr::proto_childN, State, Data)
     >::type

Now if Grammar::proto_childN is *not* derived from pass_through,
then that would make the above an object CTOR call.  Unless
the N-th child has a 3 element CTOR, then this will fail to
compile. OTOH, if then N-th child is derived from pass_through
(IOW, if the grammar and transform are bundled), then this
will compile.

Eric, is that about right?

_______________________________________________
(Continue reading)

Permalink | Reply |
headers
Eric Niebler | 17 Apr 01:09
Picon

Re: [Proto]Rationale for grammar/transform bundling (was Re: [Proto] Review result

Larry Evans wrote:
> There was also an issue with separation of transforms from grammars.
> This mixing made it hard for me to understand transforms.  I believe
> separating the two would make understanding for other novice users
> easier also.  Of course I'm not even real sure that separation is
> possible, as I intimated with the '*highly* speculative' qualifier
> in my review.  However, since then I've been trying to separate the
> two.  This lead me to understand *maybe* why bundling the two is
> necessary.  The pass_through transform docs contain:
> 
>    , boost::result_of
>      < Grammar::proto_childN(Expr::proto_childN, State, Data)
>      >::type
> 
> Now if Grammar::proto_childN is *not* derived from pass_through,
> then that would make the above an object CTOR call.

No, you are confusing how boost::result_of and proto::when interpret 
function types. result_of has a protocol, documented in TR1, for 
calculating the return type of a function or function object given a 
function type as above. proto::when has a different convention, which 
doesn't come into play here.

> Unless
> the N-th child has a 3 element CTOR, then this will fail to
> compile. OTOH, if then N-th child is derived from pass_through
> (IOW, if the grammar and transform are bundled), then this
> will compile.
> 
> Eric, is that about right?
(Continue reading)

Permalink | Reply |

Gmane