Markus Werle wrote:
Hi!
This is a proposal for extra text which might have helped me to catch some things right from the beginning:
Section "Accessing Children Nodes": Subsection "Expression Nodes as fusion sequnces" After "... arguments in order" please insert an improved version of the following paragraph (intended for first-contact-to-proto people like me)
--- Note that in C++ operators are nothing else but special syntax for operations that can be written as function calls, ...
<snip> OK.
;-) \footnote{Once in a time binary operator+ was tagged tag::plus, which led to trouble for the tag name of unary operator+. A lot of crazy proposals for the tag name were made, now we simply use tag::binary_plus and tag::unary_plus, no further discussions needed} ;-)
:-) FWIW, I (mostly) agree with this approach. s/posit/unary_plus/. I think plus stays plus, though. And the bike shed is green.
the call fun(...) has a return type of expr<tag::function, PUT_SOME_CODE_HERE, ....> The integers are automatically wrapped in terminal<int>s. That's why proto is so cool.
I hope that's not Proto's most compelling feature. <snip>
we use a compile time algorithm which drops the first element from the list before pushing the result through other very useful algorithms of boost::fusion - in this example for_each and transform
I agree something like this is needed to make the section on Fusion integration more understandable.
(Did we already mention that you are lost with proto if you do not know fusion?)
It helps, but users should be required to read Fusion's docs to understand Proto. If that's the case, I need to fix it. -- Eric Niebler Boost Consulting www.boost-consulting.com