Eric Niebler | 8 Aug 23:52

new proto transforms in development

In response to feedback that proto transforms are too hard to write, and 
per some suggestions from Dave A., I'm considering making some changes 
to proto's transform protocol. The new code is in 
https://svn.boost.org/svn/boost/branches/proto/v3. Here, for example, is 
how the toy spirit example looks using the new transforms:

http://svn.boost.org/trac/boost/browser/branches/proto/v3/libs/xpressive/proto/test/toy_spirit3.cpp

This is just a heads up, and a call for feedback. No docs yet, just the 
examples.

--

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com

The Astoria Seminar ==> http://www.astoriaseminar.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
Andy Elvey | 9 Aug 08:47

Re: new proto transforms in development

On Wed, 2007-08-08 at 14:55 -0700, Eric Niebler wrote:
> In response to feedback that proto transforms are too hard to write, and 
> per some suggestions from Dave A., I'm considering making some changes 
> to proto's transform protocol. The new code is in 
> https://svn.boost.org/svn/boost/branches/proto/v3. Here, for example, is 
> how the toy spirit example looks using the new transforms:
> 
> http://svn.boost.org/trac/boost/browser/branches/proto/v3/libs/xpressive/proto/test/toy_spirit3.cpp
> 
> This is just a heads up, and a call for feedback. No docs yet, just the 
> examples.
> 
*Very* nice "toy Spirit" there, Eric!  The code is almost "Pythonic" in its elegance... :-) 
Great work! 
- Andy 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
Larry Evans | 29 Jan 17:07

Re: new proto transforms in development

On 08/08/07 16:55, Eric Niebler wrote:
[snip]
> https://svn.boost.org/svn/boost/branches/proto/v3. Here, for example, is 
> how the toy spirit example looks using the new transforms:
> 
> http://svn.boost.org/trac/boost/browser/branches/proto/v3/libs/xpressive/proto/test/toy_spirit3.cpp
> 

Eric, this looks interesting and I'm trying to figure out how to add
non-terminals, semantic attributes and actions to the grammar.
Do you have any ideas on how to do this?

-regards,
Larry

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Eric Niebler | 29 Jan 17:28

Re: new proto transforms in development

Larry Evans wrote:
> On 08/08/07 16:55, Eric Niebler wrote:
> [snip]
>> https://svn.boost.org/svn/boost/branches/proto/v3. Here, for example, is 
>> how the toy spirit example looks using the new transforms:
>>
>> http://svn.boost.org/trac/boost/browser/branches/proto/v3/libs/xpressive/proto/test/toy_spirit3.cpp
> 
> Eric, this looks interesting and I'm trying to figure out how to add
> non-terminals, semantic attributes and actions to the grammar.
> Do you have any ideas on how to do this?

It would help if you had a specific question about Proto. Can you 
describe the problems you're running into?

--

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Larry Evans | 29 Jan 18:10

Re: new proto transforms in development

On 01/29/08 10:28, Eric Niebler wrote:
> Larry Evans wrote:
>> On 08/08/07 16:55, Eric Niebler wrote:
>> [snip]
>>> https://svn.boost.org/svn/boost/branches/proto/v3. Here, for example, is 
>>> how the toy spirit example looks using the new transforms:
>>>
>>> http://svn.boost.org/trac/boost/browser/branches/proto/v3/libs/xpressive/proto/test/toy_spirit3.cpp
>> Eric, this looks interesting and I'm trying to figure out how to add
>> non-terminals, semantic attributes and actions to the grammar.
>> Do you have any ideas on how to do this?
> 
> It would help if you had a specific question about Proto. Can you 
> describe the problems you're running into?
> 

I haven't really tried, but I've struggled before with understanding
how to do things with proto; so, I was hoping you could lead the way.

One specific example would be the arithmetic expression grammar.
My first guess at how to do this would be to add another element,
say SpiritNonterminal, to:

         struct SpiritExpr
           : or_<
                 SpiritSequence
               , SpiritAlternate
               , SpiritDirective
               , SpiritTerminal
             >
(Continue reading)

Larry Evans | 29 Jan 18:26

Re: new proto transforms in development

On 01/29/08 11:10, Larry Evans wrote:
> On 01/29/08 10:28, Eric Niebler wrote:
>> Larry Evans wrote:
>>> On 08/08/07 16:55, Eric Niebler wrote:
>>> [snip]
>>>> https://svn.boost.org/svn/boost/branches/proto/v3. Here, for example, is 
>>>> how the toy spirit example looks using the new transforms:
>>>>
>>>> http://svn.boost.org/trac/boost/browser/branches/proto/v3/libs/xpressive/proto/test/toy_spirit3.cpp
>>> Eric, this looks interesting and I'm trying to figure out how to add
>>> non-terminals, semantic attributes and actions to the grammar.
>>> Do you have any ideas on how to do this?
>> It would help if you had a specific question about Proto. Can you 
>> describe the problems you're running into?
>>
> 
> I haven't really tried, but I've struggled before with understanding
> how to do things with proto; so, I was hoping you could lead the way.
> 
> One specific example would be the arithmetic expression grammar.
> My first guess at how to do this would be to add another element,
> say SpiritNonterminal, to:
> 
>          struct SpiritExpr
>            : or_<
>                  SpiritSequence
>                , SpiritAlternate
>                , SpiritDirective
>                , SpiritTerminal
>              >
(Continue reading)

Eric Niebler | 29 Jan 20:07

Re: new proto transforms in development

Larry Evans wrote:
> On 01/29/08 10:28, Eric Niebler wrote:
>> Larry Evans wrote:
>>> I'm trying to figure out how to
>>> add non-terminals, semantic attributes and actions to the
>>> grammar. Do you have any ideas on how to do this?
>> It would help if you had a specific question about Proto. Can you 
>> describe the problems you're running into?
> 
> I haven't really tried, but I've struggled before with understanding 
> how to do things with proto;

Take another look. Things are vastly simpler with the new transforms.

> I was hoping you could lead the way.

Heh, I have enough on my plate without reimplementing all of Spirit
just for kicks. ;-)

> One specific example would be the arithmetic expression grammar. My
> first guess at how to do this would be to add another element, say
> SpiritNonterminal, to:
> 
> struct SpiritExpr : or_< SpiritSequence , SpiritAlternate ,
> SpiritDirective , SpiritTerminal
>> 
> {};

SpiritSequence, SpiritAlternate and SpiritDirective are all
non-terminals. I'm not sure what your proposed SpiritNonterminal is for. 
(Continue reading)

Larry Evans | 30 Jan 14:59

Re: new proto transforms in development

On 01/29/08 13:07, Eric Niebler wrote:
> Larry Evans wrote:
>> On 01/29/08 10:28, Eric Niebler wrote:
>>> Larry Evans wrote:
>>>> I'm trying to figure out how to
>>>> add non-terminals, semantic attributes and actions to the
>>>> grammar. Do you have any ideas on how to do this?
>>> It would help if you had a specific question about Proto. Can you 
>>> describe the problems you're running into?
>> I haven't really tried, but I've struggled before with understanding 
>> how to do things with proto;
> 
> 
> Take another look. Things are vastly simpler with the new transforms.
> 
> 
>> I was hoping you could lead the way.
> 
> Heh, I have enough on my plate without reimplementing all of Spirit
> just for kicks. ;-)

Yeah, I felt sorta guilty about asking you.  I've started
deciphering toy_spirit3.cpp myself now.

> 
> 
>> One specific example would be the arithmetic expression grammar. My
>> first guess at how to do this would be to add another element, say
>> SpiritNonterminal, to:
>>
(Continue reading)

Eric Niebler | 30 Jan 16:55

Re: new proto transforms in development

Larry Evans wrote:
> However, I was looking at toy_spirit2 and was trying to fathom:
> 
>          return parse_fun(SpiritExpr()(rule, 0, is_case_sensitive));
> 
> So I looked at:
> 
> http://boost-sandbox.sourceforge.net/libs/proto/doc/html/boost/proto/control/or_.html
> 
> and it showed no or_<...>::operator().  OTOH, the source does at
> matches.hpp:501:
> 
>                  template<typename Expr, typename State, typename
>                    Visitor>
>                  typename result<void(Expr, State, Visitor)>::type
>                  operator ()(Expr const &expr, State const &state,
>                    Visitor &visitor) const
>                  {...}
> 
> Shouldn't the or_ .html show the operator()?

It's a Doxygen bug. Any function that has a return type that uses 
result_of doesn't get emitted by Doxygen. I guess Dox doesn't expect to 
find parens () in a return type.

I'm still looking for a work-around.

--

-- 
Eric Niebler
Boost Consulting
(Continue reading)

Eric Niebler | 7 Feb 05:15

Re: new proto transforms in development

Eric Niebler wrote:
> Larry Evans wrote:
>> However, I was looking at toy_spirit2 and was trying to fathom:
>>
>>          return parse_fun(SpiritExpr()(rule, 0, is_case_sensitive));
>>
>> So I looked at:
>>
>> http://boost-sandbox.sourceforge.net/libs/proto/doc/html/boost/proto/control/or_.html
>>
>> and it showed no or_<...>::operator().
> 
> It's a Doxygen bug. Any function that has a return type that uses 
> result_of doesn't get emitted by Doxygen. I guess Dox doesn't expect to 
> find parens () in a return type.

FYI, it looks like the latest Doxygen (1.5.4) has fixed this bug, so all 
the operator() overloads are showing up in the docs now.

--

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Larry Evans | 10 Feb 20:53

Re: new proto transforms in development

On 01/29/08 13:07, Eric Niebler wrote:
> Larry Evans wrote:
>> On 01/29/08 10:28, Eric Niebler wrote:
>>> Larry Evans wrote:
>>>> I'm trying to figure out how to
>>>> add non-terminals, semantic attributes and actions to the
>>>> grammar. Do you have any ideas on how to do this?
>>> It would help if you had a specific question about Proto. Can you 
>>> describe the problems you're running into?
>> I haven't really tried, but I've struggled before with understanding 
>> how to do things with proto;
> 
> 
> Take another look. Things are vastly simpler with the new transforms.
> 
> 
[snip]
Eric,

I've been struggling with this for several days now.  That attached
file illustrates the problems I'm having.  In short, I want
to create a transform from one algebra to another,
So, the first step is to define the terminals in the intial
algebra.  That's the.

template<alg_num Num>
struct alg_expr0
: proto::terminal<alg_tag0<Num> >
{};

(Continue reading)

Eric Niebler | 11 Feb 01:30

Re: new proto transforms in development

Larry Evans wrote:
> Eric,
> 
> I've been struggling with this for several days now.  That attached
> file illustrates the problems I'm having.  In short, I want
> to create a transform from one algebra to another,
> So, the first step is to define the terminals in the intial
> algebra.  That's the.
> 
> template<alg_num Num>
> struct alg_expr0
> : proto::terminal<alg_tag0<Num> >
> {};

OK.

> Next I need to build expressions in this algebra.  I tried to do this
> first with a unary expression.  That's the:
> 
> template<alg_num Anum,class Expr0>
> struct alg_expr1
> : unary_expr<alg_tag1<Anum>,Expr0>
> {
>     //definition of result template and operator() template
>     //based on corresponding unary_arity struct in
>     //libs/xpressive/proto/test/examples.cpp.
>     //(see attachment)
> };

I don't know what this is. You're inheriting from unary_expr, so you 
(Continue reading)

Larry Evans | 11 Feb 15:44

semantic attributes howto (was Re: new proto transforms in development

Hi, Eric.

Thanks very much for the quick response!

On 02/10/08 18:30, Eric Niebler wrote:
 > Larry Evans wrote:
 >> Eric,
 >>
 >> I've been struggling with this for several days now.  That attached
 >> file illustrates the problems I'm having.  In short, I want
 >> to create a transform from one algebra to another,
 >> So, the first step is to define the terminals in the intial
 >> algebra.  That's the.
 >>
 >> template<alg_num Num>
 >> struct alg_expr0
 >> : proto::terminal<alg_tag0<Num> >
 >> {};
 >
 >
 > OK.
 >
 >
 >> Next I need to build expressions in this algebra.  I tried to do this
 >> first with a unary expression.  That's the:
 >>
 >> template<alg_num Anum,class Expr0>
 >> struct alg_expr1
 >> : unary_expr<alg_tag1<Anum>,Expr0>
 >> {
(Continue reading)

Larry Evans | 12 Feb 12:13

nullary make_expr::op() fails compile (was Re: semantic attributes howto (was Re: new proto transforms in development

On 02/11/08 08:44, Larry Evans wrote:
[snip]
>  > If so, try something like this:
>  >
>  > // A callable transform that makes expressions
>  > // with alg_tag1<Anum> tag type
>  > typedef
>  >      functional::make_expr<alg_tag1<Anum> >
>  > _make_alg_expr1;
>  >
>  > when<
>  >      // Match logical_not<nullary_type> expressions:
>  >      logical_not<nullary_type>
>  >      // Take the nullary_type child, wrap it in an
>  >      // alg_expr1 node:
>  >    , _make_alg_expr1(_arg)
>  >  >
>  >
>  > Try to avoid defining primitive transforms (with nested result<>
>  > templates and operator() overloads). They're harder to work with. You
>  > can do pretty much anything you need with high-level lambdas such as the
>  > one above. They're concise and powerful.
>  >
>  > HTH,
>  >
> OK.  I'll try that next.
[snip]

The functional::make_expr works for unary but not for nullary 
expressions.  Looking at:
(Continue reading)

Larry Evans | 12 Feb 12:42

Re: nullary make_expr::op() fails compile (was Re: semantic attributes howto (was Re: new proto transforms in development

On 02/12/08 05:13, Larry Evans wrote:
[snip]
> 
> I'd expected the expression, mk(), to compile, where mk has type:
>    _make_alg_expr1
> however, I get an error about no matching call to a nullary function.
> 
> The attachments show the details.
The previous .cpp attachment had some of my private debug code which
was partially disabled by the //#define DEBUG_PRINT.  It's
completely disabled with the current attachement so that you
should be able to compile it to see the error.
Attachment (make_expr_test.cpp): text/x-c++src, 1248 bytes
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spirit-devel mailing list
Spirit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-devel
Eric Niebler | 13 Feb 21:05

Re: nullary make_expr::op() fails compile (was Re: semantic attributes howto (was Re: new proto transforms in development

Larry Evans wrote:
<snip>

It makes no sense to create an expression with no children. Even a 
terminal node has data. make_expr() must take at least one argument. 
That's by design.

--

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Larry Evans | 3 Mar 02:34

Re: semantic attributes howto (was Re: new proto transforms in development

On 02/11/08 08:44, Larry Evans wrote:
[snip]
> An example of what I was *trying* to do is now in boost vault here:
> 
> http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=toy_attract.pair.cpp&directory=Strings%20-%20Text%20Processing&PHPSESSID=ab51206c9d980155d142f5bcef8e00ee
> 
> The semantic attribute for the grammar terminals is the:
> 
>          template<TerminalIndex IndexValue>
>          struct SpiritTermAttr;
> 

I tried to create a minimal test showing the essence or what
I'm trying to do.  It's in the boost vault in same directory as
above but in the pass_through.experiments.zip file.

In essence, what I'm trying to do is something like
algebraic homomorphism:

http://planetmath.org/encyclopedia/HomomorphismBetweenAlgebraicSystems.html

In pass_through.experiments.cpp, the arityI homomorphisms correspond to
xfrmI proto transforms, for I=0,1.  The particular homomorphism is
given by specicalizing on the visitor argument to the
xfrmI::operator()(expr,state,visitor) method.
For I=0, the morphism is from proto::terminals to alg0 template
instances,  For I=1, the morphism is from proto::unary_expr to alg1 
template instances.  There's an obvious extension to I>1.  This
combination of xfrmI for i=0,N, where N is the maximum arity
of the grammar templates and then specifying a proto::or_ with
(Continue reading)

Eric Niebler | 6 Mar 20:35

Re: semantic attributes howto (was Re: new proto transforms in development

Larry Evans wrote:
> In pass_through.experiments.cpp, the arityI homomorphisms correspond to
> xfrmI proto transforms, for I=0,1.  The particular homomorphism is
> given by specicalizing on the visitor argument to the
> xfrmI::operator()(expr,state,visitor) method.
> For I=0, the morphism is from proto::terminals to alg0 template
> instances,  For I=1, the morphism is from proto::unary_expr to alg1 
> template instances.  There's an obvious extension to I>1.  This
> combination of xfrmI for i=0,N, where N is the maximum arity
> of the grammar templates and then specifying a proto::or_ with
> when's where the lhs is the source expression for arity I and the xfrmI
> is the set of target's for the morphisms specifies the complete
> homomorphisms, where the number of homomorphism corresponds to the
> number of specializations of xfrmI::operator() on the visitor template
> parameter.

<snip>

> Does anyone see a better way to implement algebraic morphism with
> proto?

I can't say I fully understand what you're trying to do. But maybe this 
gets you going in the right direction.

#include <string>
#include <iostream>
#include <typeinfo>
#include <boost/xpressive/proto/proto.hpp>
#include <boost/xpressive/proto/transform.hpp>

(Continue reading)

Larry Evans | 7 Mar 14:06

Re: semantic attributes howto (was Re: new proto transforms in development

On 03/06/08 13:35, Eric Niebler wrote:
 > Larry Evans wrote:
[snip]
 >
 > <snip>
 >
 >> Does anyone see a better way to implement algebraic morphism with
 >> proto?
 >
 > I can't say I fully understand what you're trying to do.
 > But maybe this gets you going in the right direction.
 >
[snip]
 > template<typename Tag, typename AlgNum>
 > struct alg0
 > {};
 >
 > template<typename Tag, typename AlgNum, typename Alg0>
 > struct alg1
 > {};
 >
 > template<typename Tag, typename AlgNum, typename Alg0, typename Alg1>
 > struct alg2
 > {};
 >
 > struct Morphisms
 >    : or_<
 >          // Use the terminal type as the "tag"
 >          when<
 >              terminal<_>
(Continue reading)

Larry Evans | 9 Mar 11:46

proto_morphisms method fails in SpiritTerminal (was Re: semantic attributes howto...

On 03/07/08 07:06, Larry Evans wrote:
> On 03/06/08 13:35, Eric Niebler wrote:
>  > Larry Evans wrote:
> [snip]
>  >
>  > <snip>
>  >
>  >> Does anyone see a better way to implement algebraic morphism with
>  >> proto?
>  >
>  > I can't say I fully understand what you're trying to do.
>  > But maybe this gets you going in the right direction.
>  >
> [snip]
>  > template<typename Tag, typename AlgNum>
>  > struct alg0
>  > {};
>  >
>  > template<typename Tag, typename AlgNum, typename Alg0>
>  > struct alg1
>  > {};
>  >
>  > template<typename Tag, typename AlgNum, typename Alg0, typename Alg1>
>  > struct alg2
>  > {};
>  >
>  > struct Morphisms
>  >    : or_<
>  >          // Use the terminal type as the "tag"
>  >          when<
(Continue reading)

Larry Evans | 9 Mar 13:24

Re: proto_morphisms method fails in SpiritTerminal (was Re: semantic attributes howto...

On 03/09/08 05:46, Larry Evans wrote:
[snip]
> I tried this method of using _visitor with something like the alg0;
> ( the SpiritTermSymbol in attachement ); however for some reason
> the compiler is not using _visitor to retrieve the Visitor part
> of the operator()(expr,state,visitor).  Instead, it's just subsituting
> that as the type and this causes the 'undefine type' error.  The
> relevant parts of compile output are:
> 
> <-- cut here --
> 
> gcc.compile.c++ 
>
../../../../../bin.v2/sandbox/lje/libs/proto/experiments3/gcc-4.1/debug/link-static/when_result_test.o 
> 
> when_result_test.cpp: In function 'bool boost::spirit2::parse_impl(T) 
> [with T = int]':
> when_result_test.cpp:127:   instantiated from here
> when_result_test.cpp:118: error: invalid use of undefined type 'struct 
> boost::spirit2::SpiritTermSymbol<ident, boost::proto::transform::visitor>'
> when_result_test.cpp:34: error: declaration of 'struct 
> boost::spirit2::SpiritTermSymbol<ident, boost::proto::transform::visitor>'
> when_result_test.cpp:118: error: 'expr_parse_valu' has incomplete type
> 
>  >-- cut here --
> 
> What am I doing wrong?
> 

The solution is making it more like proto_morphisms.cpp.  IOW, use
(Continue reading)

Eric Niebler | 9 Mar 16:28

Re: proto_morphisms method fails in SpiritTerminal (was Re: semantic attributes howto...

Larry Evans wrote:
> 
> What am I doing wrong?
> 

>         // A grammar terminal symbol
>         enum TerminalIndex
>         { ident   //identifier
>         , op_plus //plus operator
>         };
>         template<TerminalIndex IndexValue,class Gvisitor>
>         struct SpiritTermSymbol
>         ;

Don't use non-type template parameters.

--

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Larry Evans | 30 Jan 22:38

or_<> and and_<> meaning? (was Re: new proto transforms in development

On 08/08/07 16:55, Eric Niebler wrote:
> to proto's transform protocol. The new code is in 
> https://svn.boost.org/svn/boost/branches/proto/v3. Here, for example, is 
> how the toy spirit example looks using the new transforms:
[snip]
> This is just a heads up, and a call for feedback. No docs yet, just the 
> examples.
> 
> 
In matches.hpp:71 there's:

             template<bool B, typename Expr, typename G0>
             struct or1
               : mpl::bool_<B>
             {
                 typedef G0 which;
             };

Doesn't this mean or_<> is not valid?  Likewise for and_<>.
Instead, I'd think there would be an or0 with a which typedef'ed
to some type which matches nothing.  IOW, it would be the identity
for the or_ operation.  Likewise, for and_, and0 would match
everything.  Similarly, the and_<...>::which would be some type
int ... which didn't match an expression.

Why: in boolean algebra as well as category theory and lattice theory,
there are duals.  I'm just guessing but it might be good to have
something similar with proto.

The attached code runs without triggering any errors, which
(Continue reading)

Larry Evans | 31 Jan 05:37

Re: or_<> and and_<> meaning? (was Re: new proto transforms in development

On 01/30/08 15:38, Larry Evans wrote:
> On 08/08/07 16:55, Eric Niebler wrote:
>> to proto's transform protocol. The new code is in 
[snip]
> In matches.hpp:71 there's:
> 
> 
>             template<bool B, typename Expr, typename G0>
>             struct or1
>               : mpl::bool_<B>
>             {
>                 typedef G0 which;
>             };
> 
> Doesn't this mean or_<> is not valid?  Likewise for and_<>.
> Instead, I'd think there would be an or0 with a which typedef'ed
> to some type which matches nothing.  IOW, it would be the identity
> for the or_ operation.  Likewise, for and_, and0 would match
> everything.  Similarly, the and_<...>::which would be some type
> int ... which didn't match an expression.
> 
[snip]

Another method would be to just use mpl's find_if<Seq,Pred>
where, if Seq is or_ the Pred would just be the same:

  matches_<Expr, typename G1::proto_base_expr>::value

used in matches.hpp except, of course, Pred would have
to be some matches_curry<Expr>::matches_, IOW:
(Continue reading)

Eric Niebler | 31 Jan 17:26

Re: or_<> and and_<> meaning? (was Re: new proto transforms in development


Larry Evans wrote:
> Another method would be to just use mpl's find_if<Seq,Pred>
> where, if Seq is or_ the Pred would just be the same:
> 
>   matches_<Expr, typename G1::proto_base_expr>::value
> 
> used in matches.hpp except, of course, Pred would have
> to be some matches_curry<Expr>::matches_, IOW:
> 
>    template<class Expr>struct matches_curry
>    {
>          template<class G> struct matches_
>          :   proto::matches_<Expr, typename G::proto_base_expr>
>          {};
>    };
> 
> This would reuse mpl's find_if instead of rolling your own
> which is, AFAICT, what's happending in matches.hpp.

I once had a version of proto that was built on top of mpl and fusion. 
Compiles were sloooow. I've replaced as much template metaprogramming in 
proto with preprocessor metaprogramming as possible. The implementation 
of matches<> is highly optimized for improved compile times. So no, I'm 
not interested in code reuse here.

--

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com
(Continue reading)

Eric Niebler | 31 Jan 17:23

Re: or_<> and and_<> meaning? (was Re: new proto transforms in development

Larry Evans wrote:
> On 08/08/07 16:55, Eric Niebler wrote:
>> to proto's transform protocol. The new code is in 
>> https://svn.boost.org/svn/boost/branches/proto/v3. Here, for example, 
>> is how the toy spirit example looks using the new transforms:
> [snip]
>> This is just a heads up, and a call for feedback. No docs yet, just 
>> the examples.
>>
> In matches.hpp:71 there's:
> 
>             template<bool B, typename Expr, typename G0>
>             struct or1
>               : mpl::bool_<B>
>             {
>                 typedef G0 which;
>             };
> 
> Doesn't this mean or_<> is not valid?  Likewise for and_<>.

Yes, or_<> and and_<> require at least two parameters, which you can see 
from their forward declarations:

     template<
         typename Grammar0
       , typename Grammar1
       , BOOST_PP_ENUM_PARAMS_WITH_A_DEFAULT(
             BOOST_PP_SUB(BOOST_PROTO_MAX_LOGICAL_ARITY,2)
           , typename G
           , void
(Continue reading)

Larry Evans | 1 Feb 06:06

Re: or_<> and and_<> meaning? (was Re: new proto transforms in development

On 01/31/08 10:23, Eric Niebler wrote:
> Larry Evans wrote:
[snip]
> 
>> Instead, I'd think there would be an or0 with a which typedef'ed
>> to some type which matches nothing.  IOW, it would be the identity
>> for the or_ operation.  Likewise, for and_, and0 would match
>> everything.  Similarly, the and_<...>::which would be some type
>> int ... which didn't match an expression.
>>
>> Why: in boolean algebra as well as category theory and lattice theory,
>> there are duals.  I'm just guessing but it might be good to have
>> something similar with proto.
> 
> Theory is nice, but is there a use case?
> 

Suppose you have:

   typedef and_<T0,T1,...,Tn> ands_type;
   typedef /*some grammar*/ expr_type;

such that:

   matches<expr_type,ands_type>::value

is false.  Wouldn't you like to know which T0,...,Tn
expr_type failed to match?  That could be the
nested which value.  If it does match, the nested
which value would be proto::_.  As it is, it looks
(Continue reading)

Eric Niebler | 2 Feb 22:45

Re: or_<> and and_<> meaning? (was Re: new proto transforms in development

Larry Evans wrote:
> On 01/31/08 10:23, Eric Niebler wrote:
>> Larry Evans wrote:
> [snip]
>>> Instead, I'd think there would be an or0 with a which typedef'ed
>>> to some type which matches nothing.  IOW, it would be the identity
>>> for the or_ operation.  Likewise, for and_, and0 would match
>>> everything.  Similarly, the and_<...>::which would be some type
>>> int ... which didn't match an expression.
>>>
>>> Why: in boolean algebra as well as category theory and lattice theory,
>>> there are duals.  I'm just guessing but it might be good to have
>>> something similar with proto.
>> Theory is nice, but is there a use case?
> 
> Suppose you have:
> 
>    typedef and_<T0,T1,...,Tn> ands_type;
>    typedef /*some grammar*/ expr_type;
> 
> such that:
> 
>    matches<expr_type,ands_type>::value
> 
> is false.  Wouldn't you like to know which T0,...,Tn
> expr_type failed to match?  That could be the
> nested which value.

I imagine that might be useful information, but that's not what the 
nested ::which typedef (which at the moment is a poorly hidden 
(Continue reading)

Larry Evans | 3 Feb 00:56

Re: or_<> and and_<> meaning? (was Re: new proto transforms in development

On 02/02/08 15:45, Eric Niebler wrote:
> Larry Evans wrote:
[snip]
>> Suppose you have:
>>
>>    typedef and_<T0,T1,...,Tn> ands_type;
>>    typedef /*some grammar*/ expr_type;
>>
>> such that:
>>
>>    matches<expr_type,ands_type>::value
>>
>> is false.  Wouldn't you like to know which T0,...,Tn
>> expr_type failed to match?  That could be the
>> nested which value.
> 
> 
> I imagine that might be useful information, but that's not what the 
> nested ::which typedef (which at the moment is a poorly hidden 
> implementation detail) is for. See below.
> 
> 
>> If it does match, the nested
>> which value would be proto::_.  As it is, it looks
>> like:
>>
>>    ands_type()(a_Ti, some_state, some_viz)
>>
>> where a_Ti is of type Ti, returns:
>>
(Continue reading)

Eric Niebler | 3 Feb 02:24

Re: or_<> and and_<> meaning? (was Re: new proto transforms in development

Larry Evans wrote:
> On 02/02/08 15:45, Eric Niebler wrote:
>> Correct. That's because the nested ::which typedef represents the 
>> transform to apply when an expression matches the and_<> or or_<> 
>> grammar. For or_<>, ::which is a typedef for the first grammar that 
>> matched the expression. For and_<>, it could be any one of them, really, 
>> but we need to pick one, and so by convention I pick the last one.
>>
> However, if matches<expr_type,ands_type>::value is false, you wouln't want
> to pick any of them; yet, as defined, even if the match is false, the 
> last one is picked.

It is always an error to apply a transformation to an expression that 
doesn't match the grammar. What do you think would happen if you had:

   when<plus<_,_>, mpl::plus<_left, _right>()>

and you tried to apply that transform to, say, a terminal? It's an 
error. Ditto for and_<>. The and_<> grammar has to match the expression 
if you're going to try to apply its transform to that expression.

> To avoid that, the user must guard the pick with:
> 
>    if(matches<expr_type,ands_type>::value)
>    {
>         ands_type()
>           (expr_type, some_state, some_viz);
>    }

That's an error, too. The body of the if() will be compiled even if 
(Continue reading)

Larry Evans | 3 Feb 04:20

SFINAE needed to guard transforms (was Re: or_<> and and_<> meaning? (was Re: new proto transforms in development

On 02/02/08 19:24, Eric Niebler wrote:
> Larry Evans wrote:
[snip]
>> However, if matches<expr_type,ands_type>::value is false, you wouln't want
>> to pick any of them; yet, as defined, even if the match is false, the 
>> last one is picked.
> 
[snip]
>> To avoid that, the user must guard the pick with:
>>
>>    if(matches<expr_type,ands_type>::value)
>>    {
>>         ands_type()
>>           (expr_type, some_state, some_viz);
>>    }
> 
> That's an error, too. The body of the if() will be compiled even if 
> matches<>::value is known to be false at compile time.

WOW!  That was unexpected.  I guess that's why, in toy_spirit3.cpp,
there's the pair of parse_impl's which are selected at compile-time
by SFINAE by using the disable_if and enable_if in the return types.
I think this should be emphasized in:

http://boost-sandbox.sourceforge.net/libs/proto/doc/html/boost_proto/users_guide/expression_transformation.html

with something like:

   expr -- the Proto expression to transform
     (WARNING: the transform is undefined if
(Continue reading)

Eric Niebler | 3 Feb 09:47

Re: SFINAE needed to guard transforms (was Re: or_<> and and_<> meaning?

Larry Evans wrote:
> On 02/02/08 19:24, Eric Niebler wrote:
>> Larry Evans wrote:
> [snip]
>>> However, if matches<expr_type,ands_type>::value is false, you wouln't want
>>> to pick any of them; yet, as defined, even if the match is false, the 
>>> last one is picked.
> [snip]
>>> To avoid that, the user must guard the pick with:
>>>
>>>    if(matches<expr_type,ands_type>::value)
>>>    {
>>>         ands_type()
>>>           (expr_type, some_state, some_viz);
>>>    }
>> That's an error, too. The body of the if() will be compiled even if 
>> matches<>::value is known to be false at compile time.
> 
> WOW!  That was unexpected.  I guess that's why, in toy_spirit3.cpp,
> there's the pair of parse_impl's which are selected at compile-time
> by SFINAE by using the disable_if and enable_if in the return types.

A static assert would have been enough. The use of SFINAE is a trick to 
improve the quality of the resulting error message -- dispatch to an 
empty function rather than execute metacode that is sure to fail badly 
and generate noise. That should go in a tips-n-tricks section.

But toy_spirit3.cpp doesn't exist anymore, and the branches/proto/v3 is 
dead. You should be looking at trunk for the latest proto code now.

(Continue reading)

Larry Evans | 1 Feb 19:47

Re: or_<> and and_<> meaning? (was Re: new proto transforms in development

On 01/31/08 10:23, Eric Niebler wrote:
> Larry Evans wrote:
[snip]
>> Why: in boolean algebra as well as category theory and lattice theory,
>> there are duals.  I'm just guessing but it might be good to have
>> something similar with proto.
> 
> Theory is nice, but is there a use case?
> 

Maybe and_ should be defined as the equivalent to the
fold of:

   template<class Left, class Right>
   struct and2
   //Grammar must satisfy Left and Right,
   //IOW, equivalent to current and_<Left,Right>
   ;

over and_'s arguments. After all, that's analogous
to what:

   std::accumulate(start, end, init, binop)

does.  In case of and_, the init analogue would be proto::_
and the binop analogue would be the proposed and2.
In case of or_, the init analogue would be proto::-not_<proto::_>
and the binop analogue would be or2.

Then, and_<> would be proto::_, which makes some sense, since,
(Continue reading)

Larry Evans | 1 Feb 20:09

Re: or_<> and and_<> meaning? (was Re: new proto transforms in development

On 02/01/08 12:47, Larry Evans wrote:
> On 01/31/08 10:23, Eric Niebler wrote:
>> Larry Evans wrote:
> [snip]
>>> Why: in boolean algebra as well as category theory and lattice theory,
>>> there are duals.  I'm just guessing but it might be good to have
>>> something similar with proto.
>> Theory is nice, but is there a use case?
>>
> 
> Maybe and_ should be defined as the equivalent to the
> fold of:
> 
>    template<class Left, class Right>
>    struct and2
>    //Grammar must satisfy Left and Right,
>    //IOW, equivalent to current and_<Left,Right>
>    ;
> 
[snip]
I actually had a use case for this and2 or really the analagous or2.
I had an enum or symbols representing grammar termininals.
I wasn't an or_ to represent any terminal symbol.  I produced
an iterator over the elements in the terminal symbol enum elements
, and then used that with mpl::fold to produce the required or_.
The init for that fold was proto::not_<proto::_>.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
(Continue reading)

Larry Evans | 1 Feb 20:24

Re: or_<> and and_<> meaning? (was Re: new proto transforms in development

On 02/01/08 13:09, Larry Evans wrote:
[snip]
> [snip]
> I actually had a use case for this and2 or really the analagous or2.
> I had an enum or symbols representing grammar termininals.
should be "an enum for symbols"  and "grammar terminals".
> I wasn't an or_ to represent any terminal symbol.  I produced
should be "I wanted an or_".
[snip]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Eric Niebler | 2 Feb 23:17

Re: or_<> and and_<> meaning? (was Re: new proto transforms in development

Larry Evans wrote:
> I actually had a use case for this and2 or really the analagous or2.
> I had an enum or symbols representing grammar termininals.
> I wasn't an or_ to represent any terminal symbol.  I produced
> an iterator over the elements in the terminal symbol enum elements
> , and then used that with mpl::fold to produce the required or_.
> The init for that fold was proto::not_<proto::_>.

I see some value in making or_<> synonymous with not_<_> and and_<> 
synonymous with _, and also allowing or_<T0> and and_<T0> (i.e., with 
one argument). If you would, please re-raise the issue during Proto's 
review and I'll address it.

--

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Larry Evans | 14 Feb 15:20

[proto]when docs incomplete (was Re: new proto transforms in development

On 08/08/07 16:55, Eric Niebler wrote:
> In response to feedback that proto transforms are too hard to write, and 
> per some suggestions from Dave A., I'm considering making some changes 
> to proto's transform protocol. The new code is in 
> https://svn.boost.org/svn/boost/branches/proto/v3. Here, for example, is 
> how the toy spirit example looks using the new transforms:
> 
> http://svn.boost.org/trac/boost/browser/branches/proto/v3/libs/xpressive/proto/test/toy_spirit3.cpp
> 
> This is just a heads up, and a call for feedback. No docs yet, just the 
> examples.
The page:

http://boost-sandbox.sourceforge.net/libs/proto/doc/html/boost_proto/users_guide/expression_transformation/canned_transforms/when.html

contains a table with entry

   when<Grammar,  R(A0,  A1,  ... A  N  )>:

however, it doesn't contain an entry for:

   when<Grammar, R>

OTOH, the following paragraph does contain:

   If no transform arguments are specified, as in when<Grammar, _arg>,
   the transform is assumed to be callable; that is, it is equivalent
   to when<Grammar, call<_arg> >.

However, this still does not fit with the entries in the table since
(Continue reading)

Larry Evans | 14 Feb 19:13

Re: [proto]when docs incomplete (was Re: new proto transforms in development

On 02/14/08 08:20, Larry Evans wrote:
[snip]
> The page:
> 
> http://boost-sandbox.sourceforge.net/libs/proto/doc/html/boost_proto/users_guide/expression_transformation/canned_transforms/when.html
> 
> contains a table with entry
> 
>    when<Grammar,  R(A0,  A1,  ... A  N  )>:
> 
> however, it doesn't contain an entry for:
> 
>    when<Grammar, R>
> 
[snip]
> However, this still does not fit with the entries in the table since
> there's no argument list after call<_arg>.  So what should be in
> the Returns column for when<Grammar, call<_arg> >? Maybe this:
> 
>    call<call<_arg>() >::type()(expr,state,visitor)
> 
> ?
Experimentation leads to me to believe that the following would
be a valid entry in that table:

   If column1 contains:

     when<Grammar, R>()(expr, state, visitor)

   then column 2 would contain:
(Continue reading)

Eric Niebler | 15 Feb 00:40

Re: [proto]when docs incomplete (was Re: new proto transforms in development

Larry Evans wrote:
> Experimentation leads to me to believe that the following would
> be a valid entry in that table:
> 
>    If column1 contains:
> 
>      when<Grammar, R>()(expr, state, visitor)
> 
>    then column 2 would contain:
> 
>      call<R>()(expr, state, visitor )
> 
> Is that right?

That's correct. I'll update the docs. (Sorry for the delay, I've been 
traveling.) Thanks,

--

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Larry Evans | 15 Feb 23:04

call docs simplification(was Re: new proto transforms in development

On 08/08/07 16:55, Eric Niebler wrote:
[snip]
> This is just a heads up, and a call for feedback. No docs yet, just the 
> examples.
> 
> 

http://boost-sandbox.sourceforge.net/libs/proto/doc/html/boost_proto/users_guide/expression_transformation/canned_transforms/call.html

contains in the 2nd column of the table:

   when<_, A0>()(expr, state, visitor)

However, since _ matches anything, I don't see the purpose.  Couldn't it 
be simplfied somehow to an expression just involving A0?  And now that
I look at the when docs, the 2nd column there doesn't involve Grammar
at all; so, I'm wondering if the when doc needs to be prefixed with
something that says it's only useful in an or_ of switch_, I guess.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Eric Niebler | 15 Feb 23:35

Re: call docs simplification(was Re: new proto transforms in development

Larry Evans wrote:
> http://boost-sandbox.sourceforge.net/libs/proto/doc/html/boost_proto/users_guide/expression_transformation/canned_transforms/call.html
> 
> contains in the 2nd column of the table:
> 
>    when<_, A0>()(expr, state, visitor)
> 
> However, since _ matches anything, I don't see the purpose.  Couldn't it 
> be simplfied somehow to an expression just involving A0? 

A0 can be an object transform (should be evaluated with make<>) or a 
callable transform (should be evaluated with call<>). By expressing the 
behavior in terms of when<>, these two possibilities are automatically 
accounted for.

> And now that
> I look at the when docs, the 2nd column there doesn't involve Grammar
> at all; so, I'm wondering if the when doc needs to be prefixed with
> something that says it's only useful in an or_ of switch_, I guess.

No. Although the behavior of when<> as a transform does not depend on 
Grammar, you need to use when<> whenever you want to associate a grammar 
with a transform.

--

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com

-------------------------------------------------------------------------
(Continue reading)

Larry Evans | 16 Feb 00:11

Re: call docs simplification(was Re: new proto transforms in development

On 02/15/08 16:35, Eric Niebler wrote:
> Larry Evans wrote:
>> http://boost-sandbox.sourceforge.net/libs/proto/doc/html/boost_proto/users_guide/expression_transformation/canned_transforms/call.html
>>
>> contains in the 2nd column of the table:
>>
>>    when<_, A0>()(expr, state, visitor)
>>
>> However, since _ matches anything, I don't see the purpose.  Couldn't it 
>> be simplfied somehow to an expression just involving A0? 
> 
> A0 can be an object transform (should be evaluated with make<>) or a 
> callable transform (should be evaluated with call<>). By expressing the 
> behavior in terms of when<>, these two possibilities are automatically 
> accounted for.

Yes, I guessed that maybe that was the reason; however,
I then thought, why not express these two possibilites explicitly.
IOW, instead of using when<_,X> just use the mpl::if_<...> expression
used on the rhs of the when table.  Ah, you say, but that would be
duplicating the documentation.  Well, why not provide a transform
in the library that's the rhs of the when table?  Then that transform
could be documented on it's page and used both on the when page
and on the call page.

> 
>> And now that
>> I look at the when docs, the 2nd column there doesn't involve Grammar
>> at all; so, I'm wondering if the when doc needs to be prefixed with
>> something that says it's only useful in an or_ of switch_, I guess.
(Continue reading)

Eric Niebler | 16 Feb 00:43

Re: call docs simplification(was Re: new proto transforms in development

Larry Evans wrote:
> IOW, instead of using when<_,X> just use the mpl::if_<...> expression
> used on the rhs of the when table.  Ah, you say, but that would be
> duplicating the documentation.  Well, why not provide a transform
> in the library that's the rhs of the when table?  Then that transform
> could be documented on it's page and used both on the when page
> and on the call page.

Such a transform would always have the same behavior as when<_,A0>, so 
it's not needed.

> I actually ran a test where the lhs of the
> when was 1) _ and then 2) not_<_> and then applied this to
> some (Expr, State, Visitor).  I got the same answer.  So, AFAICT,
> the only use is within some other proto construct.

The implementation lets you get away with that, but it's a violation of 
when's preconditions. The expression passed to when's operator() must 
match Grammar. I see that I haven't documented that, though. I've made 
the change locally.

--

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
(Continue reading)

Larry Evans | 16 Feb 19:25

Re: call docs simplification(was Re: new proto transforms in development

On 02/15/08 17:43, Eric Niebler wrote:
 > Larry Evans wrote:
 >> IOW, instead of using when<_,X> just use the mpl::if_<...> expression
 >> used on the rhs of the when table.  Ah, you say, but that would be
 >> duplicating the documentation.  Well, why not provide a transform
 >> in the library that's the rhs of the when table?  Then that transform
 >> could be documented on it's page and used both on the when page
 >> and on the call page.
 >
 > Such a transform would always have the same behavior as when<_,A0>, so
 > it's not needed.

I agree it's not needed for the specification of proto::call; however,
it would be easier for readers of that specification.  The reason it
would be easier is because the reader wouldn't have to also read
proto::when documentation to understand proto::call documentation.
Instead, the reader would just have to read the documentation for the
proposed proto construct( call it proto::if_callable), which is
simpler than the documentation for proto::when.  For example, I had to
"scratch my head" wondering why "when<_,X>" was used in the
proto::call documentation when _ would match everything.  I went back
to proto:;when documentation to see if I could find some subtlety to
justify it's use.  I couldn't; however, it just delayed my
understanding.

Maybe an analogy in the realm of arithmetic functions would help make
th case.  Suppose I had a pair of functions specified as:

   f_if_callable(y) = y*y;
   f_when(x,y) = x*f_if_callable(y);
(Continue reading)

Eric Niebler | 16 Feb 20:02

Re: call docs simplification(was Re: new proto transforms in development

Larry Evans wrote:
> I agree it's not needed for the specification of proto::call; however,
> it would be easier for readers of that specification.  The reason it
> would be easier is because the reader wouldn't have to also read
> proto::when documentation to understand proto::call documentation.
> Instead, the reader would just have to read the documentation for the
> proposed proto construct( call it proto::if_callable), which is
> simpler than the documentation for proto::when.

proto::when is central, and something users of proto need to understand 
anyway. I don't believe adding yet another transform with the same 
behavior is a simplification. Sorry.

<snip>

> So, the precondition for:
> 
>    when<_, X>()(E,S,V)
> 
> is matches<E,_>::value==true, which is vacuously true.

Precisely.

> However, that can't be the only precondition because, according to:
> 
> http://sourceforge.net/mailarchive/message.php?msg_name=47A57FB6.5060303%40boost-consulting.com
> 
> the following must also be true:
> 
>    matches<E,X>::value==true
(Continue reading)


Gmane