diff --git a/doc/acknowledgement.qbk b/doc/acknowledgment.qbk similarity index 95% rename from doc/acknowledgement.qbk rename to doc/acknowledgment.qbk index 0e7c5d1..a96e54f 100644 --- a/doc/acknowledgement.qbk +++ b/doc/acknowledgment.qbk @@ -7,7 +7,7 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) ===============================================================================/] -[section Acknowledgement] +[section Acknowledgments] # Hartmut Kaiser implemented the original lazy casts and constructors based on his original work on Spirit SE "semantic expressions" (the precursor to @@ -19,7 +19,7 @@ # Jaakko Jarvi. DA Lambda MAN! # Dave Abrahams, for his constant presence, wherever, whenever. # Aleksey Gurtovoy, DA MPL MAN! -# Doug Gregor, always a source of inpiration. +# Doug Gregor, always a source of inspiration. # Dan Marsden, did almost all the work in bringing Phoenix-2 out the door. # Eric Niebler did a 2.0 pre-release review and wrote some range related code that Phoenix stole and used in the algorithms. diff --git a/doc/actors.qbk b/doc/actors.qbk index 59872f3..2c9ac74 100644 --- a/doc/actors.qbk +++ b/doc/actors.qbk @@ -61,7 +61,7 @@ actor can take. By default, `PHOENIX_LIMIT` is set to 10.] For any Actor the following expressions must be valid: [table - [[Expression] [Return type] [Type Requirements] [Runtime Complexity]] + [[Expression] [Return type] [Type Requirements] [Run time Complexity]] [[`eval(a)`] [Any type] [] []] [[`eval(a, env)`] [Any type] [][]] [[`a(expr0, expr1..., exprN)`] [Boost.Proto expression] [][]] diff --git a/doc/advanced.qbk b/doc/advanced.qbk index d5116e8..5777d42 100644 --- a/doc/advanced.qbk +++ b/doc/advanced.qbk @@ -7,33 +7,9 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) ===============================================================================/] -[section Advanced] - -[section Phoenix in Detail] - -Section explaining how phoenix expression look like, the structure of the AST, and so on - -[section Actors] -[endsect] - -[section AST structure] -[endsect] - -[endsect] - -[section Extending] - -Section about how to extend phoenix - -[section Extending Actors] - -[endsect] - -[endsect] - -[section Transformations] - -[endsect] +[section Advanced Topics] +[include advanced/porting.qbk] +[include advanced/extending_actors.qbk] [endsect] diff --git a/doc/advanced/extending_actors.qbk b/doc/advanced/extending_actors.qbk new file mode 100644 index 0000000..0a49bed --- /dev/null +++ b/doc/advanced/extending_actors.qbk @@ -0,0 +1,180 @@ +[/============================================================================== + Copyright (C) 2001-2010 Joel de Guzman + Copyright (C) 2001-2005 Dan Marsden + Copyright (C) 2001-2010 Thomas Heller + + Distributed under the Boost Software License, Version 1.0. (See accompanying + file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) +===============================================================================/] + +[section Extending Actors] + +[link phoenix.reference.concept.actor Actors] are one of the main parts of the +library, and one of the many customization points. The default actor implementation +provides several perator() overloads which deal with the evaluation of expressions. + +For some uses cases this might not be enough. For convenience it is thinkable to +provide custom member functions which generate new expressions. An example is +the [link phoenix.reference.modules.statement.if__statement if_ Statement] which +provides an additional else member. With this the actual phoenix expression +becomes more expressive. + +Another szenario is to give actors the semantics of a certain well known interface +or concept. This tutorial like section will provide information on how to implement +a custom actor which is usable as if it where a [@http://www.sgi.com/tech/stl/Container.html STL Container]. + +[heading Requirements] + +Let's repeat what we want to have: + +[table + [[Expression] [Semantics]] + [[`a.begin()`] [Returns an iterator pointing to the first element in the container.]] + [[`a.end()`] [Returns an iterator pointing one past the last element in the container.]] + [[`a.size()`] [Returns the size of the container, that is, its number of elements.]] + [[`a.max_size()`] [Returns the largest size that this container can ever have.]] + [[`a.empty()`] [Equivalent to a.size() == 0. (But possibly faster.)]] + [[`a.swap(b)`] [Equivalent to swap(a,b)]] +] + +Additionally, we want all the operator() overloads of the regular actor. + +[heading The `container_actor`] + +The first version of our `container_actor` interface to show the general +principle. This will be continually be extended. For the sake of simplicity, +every member function generator will return [link phoenix.reference.modules.core.nothing `nothing`] +at first. + + template + struct container_actor + : actor + { + typedef actor base_type; + typedef container_actor that_type; + + container_actor( base_type const& base ) + : base_type( base ) {} + + compose::result_type const begin() { return nothing; } + compose::result_type const end() { return nothing; } + compose::result_type const size() { return nothing; } + compose::result_type const max_size() { return nothing; } + compose::result_type const empty() { return nothing; } + + // note that swap is the only function needing another container. + template + compose::result_type const swap( actor const& ) { return nothing; } + }; + +[heading Using the new actor] + +Although the member function do nothing right now, we want to test if we can use +our new actor. + +First, lets create a generator which wraps the `container_actor` around any other +expression: + + template + container_actor const + container( actor const& expr ) + { + return expr; + } + +Now lets test this: + + std::vector v; + v.push_back(0); + v.push_back(1); + v.push_back(2); + v.push_back(3); + + (container(arg1).begin())(v); + +Granted, this is not really elegant and not really practical (we coud have just +used phoenix::begin(v) from the [link phoenix.reference.modules.stl.algorithm Phoenix Algorithm Module], +but we can do better. + +Let's have a [link phoenix.reference.modules.core.arguments Argument placeholder] +which is usable as if it was a STL container: + + template + struct make_container_argument : compose_ex {}; + + typedef make_container_argument > make_con1; + make_con1::type const con1 = make_con1()(boost::mpl::int_<0>()); + // and so on ... + +The above code now changes to: + + std::vector v; + v.push_back(0); + v.push_back(1); + v.push_back(2); + v.push_back(3); + + (con1.size())(v); + +Wow, that was easy! + +[heading Adding live to our actor] + +This one will be actually even easier. + +First, we define a [link pheonix.reference.modules.function Lazy function] which +evaluates the expression we want to implement. +Following is the implementation of the size function: + + struct size_impl + { + // result_of protocol: + template + struct result; + + template + struct result + { + // Note, remove reference here, because Container can be anything + typedef typename boost::remove_reference::type container_type; + + // The result will be size_type + typedef typename container_type::size_type type; + }; + + template + typename result::type + operator()(Container const& container) const + { + return container.size(); + } + }; + +Good, this was the first part. The second part will be, to implement the size member +function of `container_actor`: + + template + struct container_actor + : actor + { + typedef actor base_type; + typedef container_actor that_type; + + container_actor( base_type const& base ) + : base_type( base ) {} + + typename result_of::function::type const + size() + { + function const f = size_impl(); + return f(*this); + } + + // the rest ... + }; + +It is left as exercise to the user to implement the missing parts by resuing +functions from the [link phoenix.reference.modules.stl.algorithm Phoenix Algorithm Module] +(The impatient take a look here: [@../example/container_actor.cpp container_actor.cpp]). + +[endsect] diff --git a/doc/advanced/porting.qbk b/doc/advanced/porting.qbk new file mode 100644 index 0000000..ac78add --- /dev/null +++ b/doc/advanced/porting.qbk @@ -0,0 +1,115 @@ +[/============================================================================== + Copyright (C) 2001-2010 Joel de Guzman + Copyright (C) 2001-2005 Dan Marsden + Copyright (C) 2001-2010 Thomas Heller + + Distributed under the Boost Software License, Version 1.0. (See accompanying + file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) +===============================================================================/] + +[section Porting from Phoenix 2.0] + +While reading the current documentation you might have noticed that the +[link phoenix.starter_kit Starter Kit] didn't change very much. This is because +a lot of effort was put into being compatible with Phoenix 2.0, at least on the +outside. + +That being said, the only major difference is the result type deduction protocol. +The everyday Phoenix-User will encounter this change only when writing +[link phoenix.reference.modules.function Functions]. + +To make your function implementations Phoenix compliant again change from +the old Phoenix result type deduction protocol to the new (standard compliant) +result type deduction protocol: + +[table + [[Phoenix 2.0] [Phoenix 3.0] [Notes]] + [ + [`` + struct is_odd_impl + { + template + struct result + { + typedef bool type; + }; + + template + bool operator()(Arg arg) const + { + return arg % 2 == 1; + } + }; + + boost::phoenix::function is_odd = is_odd_impl(); + ``] + [`` + struct is_odd_impl + { + typedef bool result_type; + + template + bool operator()(Arg arg) const + { + return arg % 2 == 1; + } + }; + + boost::phoenix::function is_odd = is_odd_impl(); + ``] + [ __note__ + The result_of protocol is particulary easy when you implement a monomorphic + function (return type not dependant on the arguments). You then just need a + single nested return_type typedef. + ] + ] + [ + [`` + struct add_impl + { + template + struct result + { + typedef Arg1; + }; + + template + Arg1 operator()(Arg1 arg1, Arg2 arg2) const + { + return arg1 + arg2; + } + }; + + boost::phoenix::function add = add_impl(); + ``] + [`` + struct add_impl + { + template + struct result; + + template + struct result + : boost::remove_reference {}; + + template + typename boost::remove_reference::type + operator()(Arg1 arg1, Arg2 arg2) const + { + return arg1 + arg2; + } + }; + + boost::phoenix::function add = add_impl(); + ``] + [__alert__ When dealing with polymorphic functions the template arguments can + be any type including cv-qualifiers and references. For that reason, the calculated + result type need to remove the reference whenever appropriate!] + ] +] + +[blurb __tip__ There is no general guideline for porting code which relies on the +internals of Phoenix 2.0. If you plan on porting your Phoenix 2.0 extensions +please refer to the next sections.] + +[endsect] diff --git a/doc/html/index.html b/doc/html/index.html index 1c0e1b2..10659af 100644 --- a/doc/html/index.html +++ b/doc/html/index.html @@ -26,7 +26,7 @@

Copyright © 2002-2005, 2010 Joel de Guzman, Dan Marsden, Thomas Heller

-

+

Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)

@@ -49,16 +49,22 @@
Lazy Functions
More
+
Advanced Topics
+
+
Porting + from Phoenix 2.0
+
Extending Actors
+
Reference
Basics
Organization
Concepts
-
Environment
Actor
-
EvaluationPolicy
Evaluator
+
EvaluationPolicy
+
Environment
Modules
@@ -127,43 +133,31 @@
Porting from Phoenix 2.0
Wrap Up
-
Acknowledgement
+
Acknowledgments
References

- + Preface

-
-

-

-

- Functional programming is so called because a program consists - entirely of functions. The main program itself is written as a function which - receives the program's input as its argument and delivers the program's output - as its result. Typically the main function is defined in terms of other functions, - which in turn are defined in terms of still more functions until at the bottom - level the functions are language primitives. -

-

-

-
-
-

-

-

- John Hughes-- Why Functional Programming - Matters -

-

-

-
+

+ Functional programming is so called because a program consists entirely + of functions. The main program itself is written as a function which receives + the program's input as its argument and delivers the program's output as its + result. Typically the main function is defined in terms of other functions, + which in turn are defined in terms of still more functions until at the bottom + level the functions are language primitives. +

+

+ John Hughes-- Why Functional Programming + Matters +

lambda_cpp

- + Description

@@ -181,7 +175,7 @@ library is organized in highly independent modules and layers.

- + How to use this manual

@@ -203,7 +197,7 @@ icons precede some text to indicate:

-

Table 1.1. Icons

+

Table 1.1. Icons

@@ -292,14 +286,12 @@

- + ...To my dear daughter, Phoenix

-

-

- +

Last revised: August 13, 2010 at 22:32:23 GMT

Last revised: August 14, 2010 at 21:32:59 GMT
diff --git a/doc/html/phoenix/acknowledgments.html b/doc/html/phoenix/acknowledgments.html new file mode 100644 index 0000000..8e68642 --- /dev/null +++ b/doc/html/phoenix/acknowledgments.html @@ -0,0 +1,84 @@ + + + +Acknowledgments + + + + + + + + +
+
+
+PrevUpHomeNext +
+
+
+
    +
  1. + Hartmut Kaiser implemented the original lazy casts and constructors based + on his original work on Spirit SE "semantic expressions" (the + precursor to Phoenix). +
    2. +
  2. + Angus Leeming implemented the container functions on Phoenix-1 which I + then ported to Phoenix-2. +
    3. +
  3. + Daniel Wallin helped with the scope module, local variables, let and lambda + and the algorithms. I frequently discuss design issues with Daniel on Yahoo + Messenger. +
    4. +
  4. + Jaakko Jarvi. DA Lambda MAN! +
    5. +
  5. + Dave Abrahams, for his constant presence, wherever, whenever. +
    6. +
  6. + Aleksey Gurtovoy, DA MPL MAN! +
    7. +
  7. + Doug Gregor, always a source of inspiration. +
    8. +
  8. + Dan Marsden, did almost all the work in bringing Phoenix-2 out the door. +
    9. +
  9. + Eric Niebler did a 2.0 pre-release review and wrote some range related + code that Phoenix stole and used in the algorithms. +
    10. +
  10. + Thorsten Ottosen; Eric's range_ex code began life as "container_algo" + in the old boost sandbox, by Thorsten in 2002-2003. +
    11. +
  11. + Jeremy Siek, even prior to Thorsten, in 2001, started the "container_algo". +
    12. +
  12. + Vladimir Prus wrote the mutating algorithms code from the Boost Wiki. +
    13. +
  13. + Daryle Walker did a 2.0 pre-release review. +
    14. +
+
+ + + +
Copyright © 2002-2005, 2010 Joel de Guzman, Dan Marsden, Thomas Heller

+ Distributed under the Boost Software License, Version 1.0. (See accompanying + file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) +

+
+
+
+PrevUpHomeNext +
+ + diff --git a/doc/html/phoenix/advanced.html b/doc/html/phoenix/advanced.html index fbc1c40..4eb3043 100644 --- a/doc/html/phoenix/advanced.html +++ b/doc/html/phoenix/advanced.html @@ -6,32 +6,18 @@ - - + +
-PrevUpHomeNext +PrevUpHomeNext
-
-
Copyright © 2002-2005, 2010 Joel de Guzman, Dan Marsden, Thomas Heller

@@ -42,7 +28,7 @@

-PrevUpHomeNext +PrevUpHomeNext
diff --git a/doc/html/phoenix/advanced/transformations.html b/doc/html/phoenix/advanced/transformations.html index 67c4374..1993900 100644 --- a/doc/html/phoenix/advanced/transformations.html +++ b/doc/html/phoenix/advanced/transformations.html @@ -7,13 +7,13 @@ - +
-PrevUpHomeNext +PrevUpHomeNext

Transformations @@ -28,7 +28,7 @@
-PrevUpHomeNext +PrevUpHomeNext
diff --git a/doc/html/phoenix/advanced_topics.html b/doc/html/phoenix/advanced_topics.html new file mode 100644 index 0000000..75e9e06 --- /dev/null +++ b/doc/html/phoenix/advanced_topics.html @@ -0,0 +1,41 @@ + + + +Advanced Topics + + + + + + + + +
+
+
+PrevUpHomeNext +
+
+
+
+
Porting + from Phoenix 2.0
+
Extending Actors
+
+
+ + + +
Copyright © 2002-2005, 2010 Joel de Guzman, Dan Marsden, Thomas Heller

+ Distributed under the Boost Software License, Version 1.0. (See accompanying + file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) +

+
+
+
+PrevUpHomeNext +
+ + diff --git a/doc/html/phoenix/advanced_topics/extending_actors.html b/doc/html/phoenix/advanced_topics/extending_actors.html new file mode 100644 index 0000000..77c249c --- /dev/null +++ b/doc/html/phoenix/advanced_topics/extending_actors.html @@ -0,0 +1,305 @@ + + + +Extending Actors + + + + + + + + +
+
+
+PrevUpHomeNext +
+
+
+

+ Actors are one of + the main parts of the library, and one of the many customization points. + The default actor implementation provides several perator() overloads which + deal with the evaluation of expressions. +

+

+ For some uses cases this might not be enough. For convenience it is thinkable + to provide custom member functions which generate new expressions. An example + is the if_ + Statement which provides an additional else member. With this the + actual phoenix expression becomes more expressive. +

+

+ Another szenario is to give actors the semantics of a certain well known + interface or concept. This tutorial like section will provide information + on how to implement a custom actor which is usable as if it where a STL Container. +

+
+ + Requirements +
+

+ Let's repeat what we want to have: +

+
++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ Expression +

+ 		+

+ Semantics +

+
+

+ a.begin() +

+ 		+

+ Returns an iterator pointing to the first element in the container. +

+
+

+ a.end() +

+ 		+

+ Returns an iterator pointing one past the last element in the container. +

+
+

+ a.size() +

+ 		+

+ Returns the size of the container, that is, its number of elements. +

+
+

+ a.max_size() +

+ 		+

+ Returns the largest size that this container can ever have. +

+
+

+ a.empty() +

+ 		+

+ Equivalent to a.size() == 0. (But possibly faster.) +

+
+

+ a.swap(b) +

+ 		+

+ Equivalent to swap(a,b) +

+
+

+ Additionally, we want all the operator() overloads of the regular actor. +

+
+ + The + container_actor +
+

+ The first version of our container_actor + interface to show the general principle. This will be continually be extended. + For the sake of simplicity, every member function generator will return + nothing + at first. +

+
template <typename Expr>
+struct container_actor
+	: actor<Expr>
+{
+	compose<null_actor>::result_type const begin() { return nothing; }
+	compose<null_actor>::result_type const end() { return nothing; }
+	compose<null_actor>::result_type const size() { return nothing; }
+	compose<null_actor>::result_type const max_size() { return nothing; }
+	compose<null_actor>::result_type const empty() { return nothing; }
+
+	// note that swap is the only function needing another container.
+	template <typename OtherExpr>
+	compose<null_actor>::result_type const swap( actor<OtherExpr> const& ) { return nothing; }
+};
+
+
+ + Using + the new actor +
+

+ Although the member function do nothing right now, we want to test if we + can use our new actor. +

+

+ First, lets create a generator which wraps the container_actor + around any other expression: +

+
  template <typename Expr>
+container_actor<Expr> const
+container( Expr const& expr )
+{
+	container_actor<Expr> const e = {{expr}};
+
+	return e;
+}
+
+

+ Now lets test this: +

+
std::vector<int> v;
+v.push_back(0);
+v.push_back(1);
+v.push_back(2);
+v.push_back(3);
+
+(container(arg1).begin())(v);
+
+

+ Granted, this is not really elegant and not really practical (we coud have + just used phoenix::begin(v) from the Phoenix + Algorithm Module, but we can do better. +

+

+ Let's have a Argument + placeholder which is usable as if it was a STL container: +

+
template <typename N>
+struct make_container_argument : compose_ex<argument, container_actor, N> {};
+
+make_container_argument<mpl::int_<0> >::type const con1 = {};
+// and so on ...
+
+

+ The above code now changes to: +

+
std::vector<int> v;
+v.push_back(0);
+v.push_back(1);
+v.push_back(2);
+v.push_back(3);
+
+(con1.size())(v);
+
+

+ Wow, that was easy! +

+
+ + Adding + live to our actor +
+

+ This one will be actually even easier. +

+

+ First, we define a Lazy + function which evaluates the expression we want to implement. Following + is the implementation of the size function: +

+
struct size_impl
+{
+	// result_of protocol:
+	template <typename Sig>
+	struct result;
+
+	template <typename This, typename Container>
+	struct result<This(Container)>
+	{
+		// Note, remove reference here, because Container can be anything
+		typedef typename boost::remove_reference<Container>::type container_type;
+
+		// The result will be size_type
+		typedef typename container_type::size_type type;
+	};
+
+	template <typename Container>
+	typename result<size_impl(Container const&)>::type
+	operator()(Container const& container) const
+	{
+		return container.size();
+	}
+};
+
+

+ Good, this was the first part. The second part will be, to implement the + size member function of container_actor: +

+
template <typename Expr>
+struct container_actor
+	: actor<Expr>
+{
+	typename result_of::function<size_impl, container_actor<Expr> >::type const
+	size()
+	{
+		function<size_impl> const f = size_impl();
+		return f(*this);
+	}
+
+	// the rest ...
+};
+
+

+ It is left as exercise to the user to implement the missing parts by resuing + functions from the Phoenix + Algorithm Module (The impatient take a look here: container_actor.cpp). +

+
+ + + +
Copyright © 2002-2005, 2010 Joel de Guzman, Dan Marsden, Thomas Heller

+ Distributed under the Boost Software License, Version 1.0. (See accompanying + file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) +

+
+
+
+PrevUpHomeNext +
+ + diff --git a/doc/html/phoenix/advanced_topics/porting_from_phoenix_2_0.html b/doc/html/phoenix/advanced_topics/porting_from_phoenix_2_0.html new file mode 100644 index 0000000..b069db3 --- /dev/null +++ b/doc/html/phoenix/advanced_topics/porting_from_phoenix_2_0.html @@ -0,0 +1,200 @@ + + + +Porting from Phoenix 2.0 + + + + + + + + +
+
+
+PrevUpHomeNext +
+
+
+

+ While reading the current documentation you might have noticed that the + Starter Kit didn't change very + much. This is because a lot of effort was put into being compatible with + Phoenix 2.0, at least on the outside. +

+

+ That being said, the only major difference is the result type deduction protocol. + The everyday Phoenix-User will encounter this change only when writing Functions. +

+

+ To make your function implementations Phoenix compliant again change from + the old Phoenix result type deduction protocol to the new (standard compliant) + result type deduction protocol: +

+
+++++ + + + + + + + + + + + + + + + + + +
+

+ Phoenix 2.0 +

+ 		+

+ Phoenix 3.0 +

+ 		+

+ Notes +

+
+

+ +

+
struct is_odd_impl
+{
+	template <typename Arg>
+	struct result
+	{
+		typedef bool type;
+	};
+
+	template <typename Arg>
+	bool operator()(Arg arg) const
+	{
+		return arg % 2 == 1;
+	}
+};
+
+boost::phoenix::function<is_odd_impl> is_odd = is_odd_impl();
+
+

+

+ 		+

+ +

+
struct is_odd_impl
+{
+	typedef bool result_type;
+
+	template <typename Arg>
+	bool operator()(Arg arg) const
+	{
+		return arg % 2 == 1;
+	}
+};
+
+boost::phoenix::function<is_odd_impl> is_odd = is_odd_impl();
+
+

+

+ 		+

+ note The result_of protocol is particulary easy + when you implement a monomorphic function (return type not dependant + on the arguments). You then just need a single nested return_type + typedef. +

+
+

+ +

+
struct add_impl
+{
+	template <typename Arg1, typename Arg2>
+	struct result
+	{
+		typedef Arg1;
+	};
+
+	template <typename Arg1, typename Arg2>
+	Arg1 operator()(Arg1 arg1, Arg2 arg2) const
+	{
+		return arg1 + arg2;
+	}
+};
+
+boost::phoenix::function<add_impl> add = add_impl();
+
+

+

+ 		+

+ +

+
struct add_impl
+{
+	template <typename Sig>
+	struct result;
+
+	template <typename This, typename Arg1, typename Arg2>
+	struct result<This(Arg1, Arg2)>
+		: boost::remove_reference<Arg1> {};
+
+	template <typename Arg1, typename Arg2>
+	typename boost::remove_reference<Arg1>::type
+	operator()(Arg1 arg1, Arg2 arg2) const
+	{
+		return arg1 + arg2;
+	}
+};
+
+boost::phoenix::function<add_impl> add = add_impl();
+
+

+

+ 		+

+ alert When dealing with polymorphic functions the + template arguments can be any type including cv-qualifiers and + references. For that reason, the calculated result type need to + remove the reference whenever appropriate! +

+
+
+

+

+ tip There is no general guideline for porting code which + relies on the internals of Phoenix 2.0. If you plan on porting your Phoenix + 2.0 extensions please refer to the next sections. +

+
+
+ + + +
Copyright © 2002-2005, 2010 Joel de Guzman, Dan Marsden, Thomas Heller

+ Distributed under the Boost Software License, Version 1.0. (See accompanying + file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) +

+
+
+
+PrevUpHomeNext +
+ + diff --git a/doc/html/phoenix/reference.html b/doc/html/phoenix/reference.html index 4e96073..830be98 100644 --- a/doc/html/phoenix/reference.html +++ b/doc/html/phoenix/reference.html @@ -6,14 +6,14 @@ - +
-PrevUpHomeNext +PrevUpHomeNext

@@ -24,10 +24,10 @@
Organization
Concepts
-
Environment
Actor
-
EvaluationPolicy
Evaluator
+
EvaluationPolicy
+
Environment
Modules
@@ -103,7 +103,7 @@
-PrevUpHomeNext +PrevUpHomeNext
diff --git a/doc/html/phoenix/reference/basics.html b/doc/html/phoenix/reference/basics.html index 879f932..22baacc 100644 --- a/doc/html/phoenix/reference/basics.html +++ b/doc/html/phoenix/reference/basics.html @@ -42,7 +42,7 @@

- + Partial Function Application

@@ -98,7 +98,7 @@ be black boxes anymore.

- + STL and higher order functions

@@ -129,7 +129,7 @@

- + Lazy Evaluation

@@ -137,11 +137,11 @@

  1. - Partial application -
    2. + Partial application +
  2. - Final evaluation -
    3. + Final evaluation +

The first stage is handled by a set of generator functions. These are your @@ -184,7 +184,7 @@ cout << (arg1 % 2 == 1)(y) << endl; // prints 0 or false

- + Forwarding Function Problem

@@ -225,7 +225,7 @@

- + Polymorphic Functions

diff --git a/doc/html/phoenix/reference/concepts.html b/doc/html/phoenix/reference/concepts.html index 588b007..d749e15 100644 --- a/doc/html/phoenix/reference/concepts.html +++ b/doc/html/phoenix/reference/concepts.html @@ -7,23 +7,23 @@ - +
-PrevUpHomeNext +PrevUpHomeNext
-
Environment
Actor
-
EvaluationPolicy
Evaluator
+
EvaluationPolicy
+
Environment
@@ -36,7 +36,7 @@
-PrevUpHomeNext +PrevUpHomeNext
diff --git a/doc/html/phoenix/reference/concepts/actor.html b/doc/html/phoenix/reference/concepts/actor.html index febcca0..c6b9cd3 100644 --- a/doc/html/phoenix/reference/concepts/actor.html +++ b/doc/html/phoenix/reference/concepts/actor.html @@ -6,21 +6,21 @@ - - + +
-PrevUpHomeNext +PrevUpHomeNext
- + Description

@@ -74,7 +74,7 @@

- + Valid Expressions
@@ -97,7 +97,7 @@

- Runtime Complexity + Run time Complexity

@@ -156,7 +156,7 @@

- + Result Type Expressions
@@ -179,7 +179,7 @@

- Compiletime Complexity + Compile time Complexity

@@ -238,7 +238,7 @@
- + Expression Semantics
@@ -281,7 +281,7 @@

Returns the N::value-th - element of an compounf expression + element of an compound expression

@@ -301,13 +301,19 @@
- + Models
@@ -320,7 +326,7 @@
-PrevUpHomeNext +PrevUpHomeNext
diff --git a/doc/html/phoenix/reference/concepts/environment.html b/doc/html/phoenix/reference/concepts/environment.html index 7309ea1..60fceaf 100644 --- a/doc/html/phoenix/reference/concepts/environment.html +++ b/doc/html/phoenix/reference/concepts/environment.html @@ -6,25 +6,25 @@ - - + +
-PrevUpHomeNext +PrevUpHomeNext
- + Description

- On an actor function call, bafore evaluating the actors expression, the + On an actor function call, before evaluating the actors expression, the actor creates an environment. Basically, the environment packages the arguments in a tuple.

@@ -51,7 +51,7 @@
- + Valid Expressions
@@ -116,7 +116,7 @@
- + Result Type Expressions
@@ -182,7 +182,7 @@
- + Expression Semantics
@@ -233,12 +233,16 @@
- + Models
@@ -251,7 +255,7 @@
-PrevUpHomeNext +PrevUpHomeNext
diff --git a/doc/html/phoenix/reference/concepts/evaluationpolicy.html b/doc/html/phoenix/reference/concepts/evaluationpolicy.html index f0c3222..4921db8 100644 --- a/doc/html/phoenix/reference/concepts/evaluationpolicy.html +++ b/doc/html/phoenix/reference/concepts/evaluationpolicy.html @@ -6,21 +6,21 @@ - - + +
-PrevUpHomeNext +PrevUpHomeNext
- + Description

@@ -57,7 +57,7 @@

- + Valid Expressions
@@ -80,7 +80,7 @@

- Runtime Complexity + Run time Complexity

@@ -104,7 +104,7 @@
- + Result Type Expressions
@@ -127,7 +127,7 @@

- Compiletime Complexity + Compile time Complexity

@@ -151,7 +151,7 @@
- + Expression Semantics
@@ -181,13 +181,13 @@

- Evalutes the Composite with the given attached data + Evaluates the Composite with the given attached data

- + Models

@@ -204,7 +204,7 @@

-PrevUpHomeNext +PrevUpHomeNext
diff --git a/doc/html/phoenix/reference/concepts/evaluator.html b/doc/html/phoenix/reference/concepts/evaluator.html index eb493f6..cd3ecac 100644 --- a/doc/html/phoenix/reference/concepts/evaluator.html +++ b/doc/html/phoenix/reference/concepts/evaluator.html @@ -6,21 +6,21 @@ - - + +
-PrevUpHomeNext +PrevUpHomeNext
- + Description

@@ -28,14 +28,14 @@ are responsible of evaluating the composed expressions.

- Various evaluators are thinkable, the main evaluator will be refered to + Various evaluators are thinkable, the main evaluator will be referred to as the default evaluator. It is implemented in terms of the Boost.Proto - default context and the various __phoenix_concpets_evaluationpolicies_. + default context and the various __phoenix_concepts_evaluationpolicies_.

Notation

-
Actor
+
Eval

Type fulfilling this concept

@@ -51,10 +51,18 @@

Object of type Expr

+
Env
+

+ Type fulfilling the Environment concept +

+
env
+

+ Object of type Env +

- + Valid Expressions
@@ -77,7 +85,7 @@

- Runtime Complexity + Run time Complexity

@@ -101,7 +109,7 @@
- + Result Type Expressions
@@ -124,7 +132,7 @@

- Compiletime Complexity + Compile time Complexity

@@ -147,7 +155,7 @@
- + Expression Semantics
@@ -183,22 +191,22 @@
- + Models
  • - eval_grammar -
    • + eval_grammar +
  • - arity -
    • + arity +
  • - no_nullary -
    • + no_nullary +
  • - switch_grammar -
    • + switch_grammar +
@@ -211,7 +219,7 @@
-PrevUpHomeNext +PrevUpHomeNext
diff --git a/doc/html/phoenix/reference/concepts/expression.html b/doc/html/phoenix/reference/concepts/expression.html new file mode 100644 index 0000000..b3380c6 --- /dev/null +++ b/doc/html/phoenix/reference/concepts/expression.html @@ -0,0 +1,135 @@ + + + +Expression + + + + + + + + +
+
+
+PrevUpHomeNext +
+
+
+
+ + Description +
+

+ An expression is considered the most general concept behind phoenix. +

+

+ All in all, everything can be an expression +

+
+

Notation

+
+
+
+ + Valid + Expressions +
+
+++++ + + + + + +
+

+ Expression +

+ 		+

+ Return Type +

+ 		+

+ Run time Complexity +

+
+
+ + Result + Type Expressions +
+
+++++ + + + + + +
+

+ Expression +

+ 		+

+ Result Type +

+ 		+

+ Compile time Complexity +

+
+
+ + Expression + Semantics +
+
++++ + + + + +
+

+ Expression +

+ 		+

+ Semantics +

+
+
+ + Models +
+
+ + + +
Copyright © 2002-2005, 2010 Joel de Guzman, Dan Marsden, Thomas Heller

+ Distributed under the Boost Software License, Version 1.0. (See accompanying + file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) +

+
+
+
+PrevUpHomeNext +
+ + diff --git a/doc/html/phoenix/reference/concepts/primitive.html b/doc/html/phoenix/reference/concepts/primitive.html new file mode 100644 index 0000000..17f1bae --- /dev/null +++ b/doc/html/phoenix/reference/concepts/primitive.html @@ -0,0 +1,34 @@ + + + +Primitive + + + + + + + + +
+
+
+PrevUpHomeNext +
+
+ + + +
Copyright © 2002-2005, 2010 Joel de Guzman, Dan Marsden, Thomas Heller

+ Distributed under the Boost Software License, Version 1.0. (See accompanying + file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) +

+
+
+
+PrevUpHomeNext +
+ + diff --git a/doc/html/phoenix/reference/modules.html b/doc/html/phoenix/reference/modules.html index 2fb131e..8979845 100644 --- a/doc/html/phoenix/reference/modules.html +++ b/doc/html/phoenix/reference/modules.html @@ -6,14 +6,14 @@ - +
-PrevUpHomeNext +PrevUpHomeNext

@@ -91,7 +91,7 @@
-PrevUpHomeNext +PrevUpHomeNext
diff --git a/doc/html/phoenix/reference/modules/bind.html b/doc/html/phoenix/reference/modules/bind.html index 1ddc6d2..7f64b55 100644 --- a/doc/html/phoenix/reference/modules/bind.html +++ b/doc/html/phoenix/reference/modules/bind.html @@ -46,7 +46,7 @@

Take note that binders are monomorphic. Rather than binding functions, the preferred way is to write true generic and polymorphic lazy-functions. - However, since most of the time we are dealing with adaptation of exisiting + However, since most of the time we are dealing with adaptation of existing code, binders get the job done faster.

diff --git a/doc/html/phoenix/reference/modules/bind/compatibility_with_other_bind_libraries.html b/doc/html/phoenix/reference/modules/bind/compatibility_with_other_bind_libraries.html index e5f8ad6..9528003 100644 --- a/doc/html/phoenix/reference/modules/bind/compatibility_with_other_bind_libraries.html +++ b/doc/html/phoenix/reference/modules/bind/compatibility_with_other_bind_libraries.html @@ -22,7 +22,7 @@

phoenix::bind passes all testcases of the Boost.Bind - library. It is therefore completely compatible and interchangable. + library. It is therefore completely compatible and interchangeable.

Note that at the current state of the library, you can not mix phoenix diff --git a/doc/html/phoenix/reference/modules/core/arguments.html b/doc/html/phoenix/reference/modules/core/arguments.html index e61abc0..06861ee 100644 --- a/doc/html/phoenix/reference/modules/core/arguments.html +++ b/doc/html/phoenix/reference/modules/core/arguments.html @@ -31,7 +31,7 @@ as an imaginary data-bin where a function argument will be placed.

- + Predefined Arguments

@@ -71,7 +71,7 @@ compose class: 

template <typename N>
-struct make_arguemnt : compose<argument, N> {};
+struct make_argument : compose<argument, N> {};

This scheme of actor creation is used throughout the library and follows @@ -79,7 +79,7 @@ for more details.

- + User Defined Arguments

@@ -107,19 +107,19 @@

- When dealing with argument placeholders the question arises wether + When dealing with argument placeholders the question arises whether you can call member functions on an argument actor.

- This is possible by supplying a costum actor + This is possible by supplying a custom actor which has a member generator function. See Extending Actors for more details.

- + Evaluating an Argument

@@ -146,7 +146,7 @@ Hello World

- + Extra Arguments

@@ -187,7 +187,7 @@ Note

- There are a few reasons why enforcing strict arity is not desireable. + There are a few reasons why enforcing strict arity is not desirable. A case in point is the callback function. Typical callback functions provide more information than is actually needed. Lambda functions are often used as callbacks. diff --git a/doc/html/phoenix/reference/modules/core/references.html b/doc/html/phoenix/reference/modules/core/references.html index db8ca71..1fa8833 100644 --- a/doc/html/phoenix/reference/modules/core/references.html +++ b/doc/html/phoenix/reference/modules/core/references.html @@ -55,7 +55,7 @@ 

add_assign(ref(i), 2)

- + Evaluating a Reference

diff --git a/doc/html/phoenix/reference/modules/core/values.html b/doc/html/phoenix/reference/modules/core/values.html index 1644431..89cfe09 100644 --- a/doc/html/phoenix/reference/modules/core/values.html +++ b/doc/html/phoenix/reference/modules/core/values.html @@ -48,7 +48,7 @@ but, as we'll see later on, there are situations where this is unavoidable.

- + Evaluating a Value

diff --git a/doc/html/phoenix/reference/modules/function.html b/doc/html/phoenix/reference/modules/function.html index 93cd320..61ad0a3 100644 --- a/doc/html/phoenix/reference/modules/function.html +++ b/doc/html/phoenix/reference/modules/function.html @@ -40,15 +40,14 @@

  • - An operator() - that takes N arguments, - and implements the function logic. -
    • + An operator() + that takes N arguments, + and implements the function logic. +
  • - A nested metafunction result<Signature> or nested typedef result_type, - following Boost.Result - Of -
    • + A nested metafunction result<Signature> or nested typedef result_type, following Boost.Result + Of +

For example, the following type implements the FunctionEval concept, in @@ -81,7 +80,7 @@

The type of Arg is either a const-reference or non-const-reference (depending - on wether your argument to the actor evaluation is a const-ref or non-const-ref). + on whether your argument to the actor evaluation is a const-ref or non-const-ref).

diff --git a/doc/html/phoenix/reference/modules/object/construction.html b/doc/html/phoenix/reference/modules/object/construction.html index 31638ec..d0d6f09 100644 --- a/doc/html/phoenix/reference/modules/object/construction.html +++ b/doc/html/phoenix/reference/modules/object/construction.html @@ -30,7 +30,7 @@ 

construct<T>(ctor_arg1, ctor_arg2, ..., ctor_argN);

- where the given parameters are the parameters to the contructor of the + where the given parameters are the parameters to the constructor of the object of type T (This implies, that type T is expected to have a constructor with a corresponding set of parameter types.).

diff --git a/doc/html/phoenix/reference/modules/object/new.html b/doc/html/phoenix/reference/modules/object/new.html index 4be4cc6..f96db37 100644 --- a/doc/html/phoenix/reference/modules/object/new.html +++ b/doc/html/phoenix/reference/modules/object/new.html @@ -30,7 +30,7 @@ 
new_<T>(ctor_arg1, ctor_arg2, ..., ctor_argN);

- where the given parameters are the parameters to the contructor of the + where the given parameters are the parameters to the contractor of the object of type T (This implies, that type T is expected to have a constructor with a corresponding set of parameter types.).

diff --git a/doc/html/phoenix/reference/modules/operator.html b/doc/html/phoenix/reference/modules/operator.html index 4257816..dbd4a38 100644 --- a/doc/html/phoenix/reference/modules/operator.html +++ b/doc/html/phoenix/reference/modules/operator.html @@ -71,21 +71,22 @@

  1. - A binary operator, except ->* - will be lazily evaluated when at least one of its - operands is an actor object (see actors). -
    2. + A binary operator, except ->* + will be lazily evaluated when at least one of + its operands is an actor object (see actors). +
  2. - Unary operators are lazily evaluted if their argument is an actor object. -
    3. + Unary operators are lazily evaluated if their argument is an actor + object. +
  3. - Operator ->* is lazily - evaluted if the left hand argument is an actor object. -
    4. + Operator ->* is lazily + evaluated if the left hand argument is an actor object. +
  4. - The result of a lazy operator is an actor object that can in turn allow - the applications of rules 1, 2 and 3. -
    5. + The result of a lazy operator is an actor object that can in turn allow + the applications of rules 1, 2 and 3. +

For example, to check the following expression is lazily evaluated: @@ -94,27 +95,33 @@

  1. - Following rule 1, arg1 + 3 is - lazily evaluated since arg1 - is an actor (see Arguments). -
    2. + Following rule 1, arg1 + 3 is + lazily evaluated since arg1 + is an actor (see Arguments). +
  2. - The result of this arg1 + 3 expression - is an actor object, following rule 4. -
    3. + The result of this arg1 + 3 expression + is an actor object, following rule 4. +
  3. - Continuing, arg1 + - 3 + 6 is again lazily evaluated. Rule 2. -
    4. + Continuing, arg1 + + 3 + + 6 is again lazily evaluated. + Rule 2. +
  4. - By rule 4 again, the result of arg1 - + 3 + 6 is - an actor object. -
    5. + By rule 4 again, the result of arg1 + + 3 + + 6 + is an actor object. +
  5. - As arg1 + - 3 + 6 is an actor, -(arg1 + 3 + 6) is lazily evaluated. Rule 2. -
    6. + As arg1 + + 3 + + 6 is an actor, -(arg1 + + 3 + + 6) is lazily evaluated. Rule 2. +

Lazy-operator application is highly contagious. In most cases, a single @@ -134,12 +141,12 @@ val(1) << 3; // Lazily evaluated

- + Supported operators

- + Unary operators

@@ -147,7 +154,7 @@ postfix: ++, --

- + Binary operators

@@ -157,7 +164,7 @@ &&, ||, ->*

- + Ternary operator

@@ -172,7 +179,7 @@ is identical, albeit in a lazy manner.

- + Member pointer operator

diff --git a/doc/html/phoenix/reference/modules/scope/lambda.html b/doc/html/phoenix/reference/modules/scope/lambda.html index 8affe70..a78c9e7 100644 --- a/doc/html/phoenix/reference/modules/scope/lambda.html +++ b/doc/html/phoenix/reference/modules/scope/lambda.html @@ -143,11 +143,11 @@

  1. - a 2-dimensional container (e.g. vector<vector<int> >) -
    2. + a 2-dimensional container (e.g. vector<vector<int> >) +
  2. - a container element (e.g. int) -
    3. + a container element (e.g. int) +

and pushes-back the element to each of the vector<int>. diff --git a/doc/html/phoenix/reference/modules/statement/throw_.html b/doc/html/phoenix/reference/modules/statement/throw_.html index a76127c..512ff87 100644 --- a/doc/html/phoenix/reference/modules/statement/throw_.html +++ b/doc/html/phoenix/reference/modules/statement/throw_.html @@ -23,7 +23,7 @@

As a natural companion to the try/catch support, the statement module - provides lazy throwing and rethrowing of exceptions. + provides lazy throwing and re-throwing of exceptions.

The syntax to throw an exception is: @@ -31,12 +31,12 @@ 

throw_(exception_expression)

- The syntax to rethrow an exception is: + The syntax to re-throw an exception is: 

throw_()

- Example: This code extends the try/catch example, rethrowing exceptions + Example: This code extends the try/catch example, re-throwing exceptions derived from runtime_error or exception, and translating other exception types to runtime_errors.

diff --git a/doc/html/phoenix/reference/modules/stl/algorithm.html b/doc/html/phoenix/reference/modules/stl/algorithm.html index 52802e9..e34f915 100644 --- a/doc/html/phoenix/reference/modules/stl/algorithm.html +++ b/doc/html/phoenix/reference/modules/stl/algorithm.html @@ -73,7 +73,7 @@

-

Table 1.6. Iteration Algorithms

+

Table 1.6. Iteration Algorithms

@@ -123,7 +123,7 @@

-

Table 1.7. Querying Algorithms

+

Table 1.7. Querying Algorithms

@@ -415,7 +415,7 @@

-

Table 1.8. Transformation Algorithms

+

Table 1.8. Transformation Algorithms

diff --git a/doc/html/phoenix/reference/modules/stl/container.html b/doc/html/phoenix/reference/modules/stl/container.html index 7b94760..dd2b71f 100644 --- a/doc/html/phoenix/reference/modules/stl/container.html +++ b/doc/html/phoenix/reference/modules/stl/container.html @@ -34,20 +34,20 @@

  • - deque -
    • + deque +
  • - list -
    • + list +
  • - map -
    • + map +
  • - multimap -
    • + multimap +
  • - vector -
    • + vector +

Indeed, should your class have member functions with the same names and @@ -56,80 +56,80 @@

  • - assign -
    • + assign +
  • - at -
    • + at +
  • - back -
    • + back +
  • - begin -
    • + begin +
  • - capacity -
    • + capacity +
  • - clear -
    • + clear +
  • - empty -
    • + empty +
  • - end -
    • + end +
  • - erase -
    • + erase +
  • - front -
    • + front +
  • - get_allocator -
    • + get_allocator +
  • - insert -
    • + insert +
  • - key_comp -
    • + key_comp +
  • - max_size -
    • + max_size +
  • - pop_back -
    • + pop_back +
  • - pop_front -
    • + pop_front +
  • - push_back -
    • + push_back +
  • - push_front -
    • + push_front +
  • - rbegin -
    • + rbegin +
  • - rend -
    • + rend +
  • - reserve -
    • + reserve +
  • - resize -
    • + resize +
  • - size -
    • + size +
  • - splice -
    • + splice +
  • - value_comp -
    • + value_comp +

The lazy functions' names are the same as the corresponding member function. @@ -137,7 +137,7 @@ does not use the member "dot" syntax.

-

Table 1.4. Sample usage

+

Table 1.4. Sample usage

@@ -215,7 +215,7 @@

-

Table 1.5. Lazy STL Container Functions

+

Table 1.5. Lazy STL Container Functions

diff --git a/doc/html/phoenix/reference/organization.html b/doc/html/phoenix/reference/organization.html index d8a3d01..a9d36fd 100644 --- a/doc/html/phoenix/reference/organization.html +++ b/doc/html/phoenix/reference/organization.html @@ -34,14 +34,14 @@ not depend on higher layers. Modules in a layer do not depend on other modules in the same layer. This means, for example, that Bind can be completely discarded if it is not required; or one could perhaps take out Operator and Statement - and just use Function, which may be desireable in a pure FP application. + and just use Function, which may be desirable in a pure FP application.

The library has grown from the original Phoenix but still comprises only header files. There are no object files to link against.

- + Core

@@ -54,11 +54,11 @@

  1. - Primitives -
    2. + Primitives +
  2. - Composites -
    3. + Composites +

Primitives provide the basic building blocks of functionality within Phoenix. @@ -70,7 +70,7 @@ can again be another composite.

-

Table 1.2. Modules

+

Table 1.2. Modules

@@ -121,7 +121,7 @@ @@ -199,7 +199,7 @@ the core module is defined in <boost/phoenix/core.hpp>.

-

Table 1.3. Includes

+

Table 1.3. Includes

- Lazy statments (e.g. if_, + Lazy statements (e.g. if_, while_)

diff --git a/doc/html/phoenix/references.html b/doc/html/phoenix/references.html index 9a4b28e..d022bca 100644 --- a/doc/html/phoenix/references.html +++ b/doc/html/phoenix/references.html @@ -6,13 +6,13 @@ - +
-PrevUpHome +PrevUpHome

@@ -20,51 +20,51 @@

  1. - Why Functional Programming Matters, John Hughes, 1989. Available online at - http://www.math.chalmers.se/~rjmh/Papers/whyfp.html. -
    2. + Why Functional Programming Matters, John Hughes, 1989. Available online + at http://www.math.chalmers.se/~rjmh/Papers/whyfp.html. +
  2. - Boost.Lambda library, Jaakko Jarvi, 1999-2004 Jaakko Jarvi, Gary Powell. - Available online at http://www.boost.org/libs/lambda/. -
    3. + Boost.Lambda library, Jaakko Jarvi, 1999-2004 Jaakko Jarvi, Gary Powell. + Available online at http://www.boost.org/libs/lambda/. +
  3. - Functional Programming in C++ using the FC++ Library: a short article introducing - FC++, Brian McNamara and Yannis Smaragdakis, August 2003. Available online - at http://www.cc.gatech.edu/~yannis/fc++/. -
    4. + Functional Programming in C++ using the FC++ Library: a short article introducing + FC++, Brian McNamara and Yannis Smaragdakis, August 2003. Available online + at http://www.cc.gatech.edu/~yannis/fc++/. +
  4. - Side-effects and partial function application in C++, Jaakko Jarvi and Gary - Powell, 2001. Available online at http://osl.iu.edu/~jajarvi/publications/papers/mpool01.pdf. -
    5. + Side-effects and partial function application in C++, Jaakko Jarvi and + Gary Powell, 2001. Available online at http://osl.iu.edu/~jajarvi/publications/papers/mpool01.pdf. +
  5. - Spirit Version 1.8.1, Joel de Guzman, Nov 2004. Available online at http://www.boost.org/libs/spirit/. -
    6. + Spirit Version 1.8.1, Joel de Guzman, Nov 2004. Available online at http://www.boost.org/libs/spirit/. +
  6. - The Boost MPL Library, Aleksey Gurtovoy and David Abrahams, 2002-2004. Available - online at http://www.boost.org/libs/mpl/. -
    7. + The Boost MPL Library, Aleksey Gurtovoy and David Abrahams, 2002-2004. + Available online at http://www.boost.org/libs/mpl/. +
  7. - Generic Programming Redesign of Patterns, Proceedings of the 5th European - Conference on Pattern Languages of Programs, (EuroPLoP'2000) Irsee, Germany, - July 2000. Available online at http://www.coldewey.com/europlop2000/papers/geraud%2Bduret.zip. -
    8. + Generic Programming Redesign of Patterns, Proceedings of the 5th European + Conference on Pattern Languages of Programs, (EuroPLoP'2000) Irsee, Germany, + July 2000. Available online at http://www.coldewey.com/europlop2000/papers/geraud%2Bduret.zip. +
  8. - A Gentle Introduction to Haskell, Paul Hudak, John Peterson and Joseph Fasel, - 1999. Available online at http://www.haskell.org/tutorial/. -
    9. + A Gentle Introduction to Haskell, Paul Hudak, John Peterson and Joseph + Fasel, 1999. Available online at http://www.haskell.org/tutorial/. +
  9. - Large scale software design, John Lackos, ISBN 0201633620, Addison-Wesley, - July 1996. -
    10. + Large scale software design, John Lackos, ISBN 0201633620, Addison-Wesley, + July 1996. +
  10. - Design Patterns, Elements of Reusable Object-Oriented Software, Erich Gamma, - Richard Helm, Ralph Jhonson, and John Vlissides, Addison-Wesley, 1995. -
    11. + Design Patterns, Elements of Reusable Object-Oriented Software, Erich Gamma, + Richard Helm, Ralph Jhonson, and John Vlissides, Addison-Wesley, 1995. +
  11. - The Forwarding Problem: Arguments Peter Dimov, Howard E. Hinnant, Dave Abrahams, - September 09, 2002. Available online: Forwarding - Function Problem. -
    12. + The Forwarding Problem: Arguments Peter Dimov, Howard E. Hinnant, Dave + Abrahams, September 09, 2002. Available online: Forwarding + Function Problem. +
@@ -77,7 +77,7 @@
-PrevUpHome +PrevUpHome
diff --git a/doc/html/phoenix/starter_kit.html b/doc/html/phoenix/starter_kit.html index 0faf9be..4fc7727 100644 --- a/doc/html/phoenix/starter_kit.html +++ b/doc/html/phoenix/starter_kit.html @@ -53,7 +53,7 @@ into high gear quickly.

- + Functors everywhere

diff --git a/doc/html/phoenix/starter_kit/lazy_functions.html b/doc/html/phoenix/starter_kit/lazy_functions.html index d633661..6094f3e 100644 --- a/doc/html/phoenix/starter_kit/lazy_functions.html +++ b/doc/html/phoenix/starter_kit/lazy_functions.html @@ -45,25 +45,25 @@ function<is_odd_impl> is_odd;

- + Things to note:

  • - Result type deduction is implemented with the help of the result_of protocol. - For more information see Boost.Result - Of -
    • + Result type deduction is implemented with the help of the result_of protocol. + For more information see Boost.Result + Of +
  • -is_odd_impl implements - the function. -
    • + is_odd_impl implements + the function. +
  • -is_odd, an instance of - function<is_odd_impl>, - is the lazy function. -
    • + is_odd, an instance of + function<is_odd_impl>, + is the lazy function. +

Now, is_odd is a truly lazy @@ -75,7 +75,7 @@ (See function.cpp)

- + Predefined Lazy Functions

diff --git a/doc/html/phoenix/starter_kit/lazy_operators.html b/doc/html/phoenix/starter_kit/lazy_operators.html index 6361bf5..7d2063a 100644 --- a/doc/html/phoenix/starter_kit/lazy_operators.html +++ b/doc/html/phoenix/starter_kit/lazy_operators.html @@ -38,13 +38,14 @@

  • - In a binary expression (e.g. 3 * arg3), - at least one of the operands must be a phoenix primitive or composite. -
    • + In a binary expression (e.g. 3 + * arg3), + at least one of the operands must be a phoenix primitive or composite. +
  • - In a unary expression (e.g. arg1++), the single operand must be a phoenix - primitive or composite. -
    • + In a unary expression (e.g. arg1++), the single operand must be a phoenix + primitive or composite. +

If these basic rules are not followed, the result is either an error, or @@ -68,7 +69,7 @@

- + First Practical Example

diff --git a/doc/html/phoenix/starter_kit/more.html b/doc/html/phoenix/starter_kit/more.html index 77f4660..77089f5 100644 --- a/doc/html/phoenix/starter_kit/more.html +++ b/doc/html/phoenix/starter_kit/more.html @@ -7,13 +7,13 @@ - +
-PrevUpHomeNext +PrevUpHomeNext

@@ -44,7 +44,7 @@
-PrevUpHomeNext +PrevUpHomeNext
diff --git a/doc/html/phoenix/starter_kit/references.html b/doc/html/phoenix/starter_kit/references.html index fac90e6..b97bad2 100644 --- a/doc/html/phoenix/starter_kit/references.html +++ b/doc/html/phoenix/starter_kit/references.html @@ -20,7 +20,7 @@ References

- References are functions. They hold a reference to a value stored somehere. + References are functions. They hold a reference to a value stored somewhere. For example, given: 

int i = 3;
diff --git a/doc/html/phoenix/starter_kit/values.html b/doc/html/phoenix/starter_kit/values.html
index cb3f553..b5bb734 100644
--- a/doc/html/phoenix/starter_kit/values.html
+++ b/doc/html/phoenix/starter_kit/values.html
@@ -32,7 +32,7 @@
         World".
       

 

-
+
         Lazy Evaluation
       

 

@@ -64,7 +64,7 @@
         anything and defers the evaluation for later.
       

 

-
+
         Callbacks
       

 

diff --git a/doc/html/phoenix/wrap_up.html b/doc/html/phoenix/wrap_up.html
index fe9fdaa..8df4cd9 100644
--- a/doc/html/phoenix/wrap_up.html
+++ b/doc/html/phoenix/wrap_up.html
@@ -7,13 +7,13 @@
 
 
 
-
+
 
 
 

 

 

-PrevUpHomeNext
+PrevUpHomeNext
 

 

 

@@ -26,26 +26,20 @@
       oriented programming in the 80s and generic programming in the 90s shaped our
       thoughts towards a more robust sense of software engineering, FP will certainly
       be a paradigm that will catapult us towards more powerful software design and
-      engineering onward into the new millenium.
+      engineering onward into the new millennium.
     

 

       Let me quote Doug Gregor of Boost.org. About functional style programming libraries:
     

-

-

-        

-

-          They're gaining acceptance, but are somewhat stunted by the ubiquitousness
-          of broken compilers. The C++ community is moving deeper into the so-called
-          "STL- style" programming paradigm, which brings many aspects
-          of functional programming into the fold. Look at, for instance, the Spirit
-          parser to see how such function objects can be used to build Yacc-like
-          grammars with semantic actions that can build abstract syntax trees on
-          the fly. This type of functional composition is gaining momentum.
-        

-

-      

-

+

+        They're gaining acceptance, but are somewhat stunted by the ubiquitousness
+        of broken compilers. The C++ community is moving deeper into the so-called
+        "STL- style" programming paradigm, which brings many aspects of
+        functional programming into the fold. Look at, for instance, the Spirit parser
+        to see how such function objects can be used to build Yacc-like grammars
+        with semantic actions that can build abstract syntax trees on the fly. This
+        type of functional composition is gaining momentum.
+      

 

       Indeed. Phoenix is another attempt to introduce more FP techniques into the
       mainstream. Not only is it a tool that will make life easier for the programmer.
@@ -69,7 +63,7 @@
 
 

 

-PrevUpHomeNext
+PrevUpHomeNext
 

 
 
diff --git a/doc/html/quickbook_HTML.manifest b/doc/html/quickbook_HTML.manifest
index 17a7716..620e1d2 100644
--- a/doc/html/quickbook_HTML.manifest
+++ b/doc/html/quickbook_HTML.manifest
@@ -10,14 +10,17 @@ phoenix/starter_kit/lazy_statements.html
 phoenix/starter_kit/construct__new__delete__casts.html
 phoenix/starter_kit/lazy_functions.html
 phoenix/starter_kit/more.html
+phoenix/advanced_topics.html
+phoenix/advanced_topics/porting_from_phoenix_2_0.html
+phoenix/advanced_topics/extending_actors.html
 phoenix/reference.html
 phoenix/reference/basics.html
 phoenix/reference/organization.html
 phoenix/reference/concepts.html
-phoenix/reference/concepts/environment.html
 phoenix/reference/concepts/actor.html
-phoenix/reference/concepts/evaluationpolicy.html
 phoenix/reference/concepts/evaluator.html
+phoenix/reference/concepts/evaluationpolicy.html
+phoenix/reference/concepts/environment.html
 phoenix/reference/modules.html
 phoenix/reference/modules/core.html
 phoenix/reference/modules/core/values.html
@@ -57,5 +60,5 @@ phoenix/reference/modules/stl/algorithm.html
 phoenix/notes.html
 phoenix/notes/porting_from_phoenix_2_0.html
 phoenix/wrap_up.html
-phoenix/acknowledgement.html
+phoenix/acknowledgments.html
 phoenix/references.html
diff --git a/doc/notes.qbk b/doc/notes.qbk
index 7cbdef8..0d510bb 100644
--- a/doc/notes.qbk
+++ b/doc/notes.qbk
@@ -11,11 +11,11 @@
 [include notes/porting_from_2_0.qbk]
 
 [/
-[section C++0x Lambdas - Differences, Similiarities]
+[section C++0x Lambdas - Differences, Similarities]
 Notes on portability with all the other existing FP libraries
 [endsect]
 
-[section BLL - Differences, Similiarities]
+[section BLL - Differences, Similarities]
 Notes on portability with all the other existing FP libraries
 [endsect]
 
diff --git a/doc/notes/performance.qbk b/doc/notes/performance.qbk
index e6c8f01..0d3e2f5 100644
--- a/doc/notes/performance.qbk
+++ b/doc/notes/performance.qbk
@@ -8,12 +8,12 @@
 
 [section Performance]
 
-This section will contain some obversations and notes about performance of the current implementation
+This section will contain some observations and notes about performance of the current implementation
 
-[section Compiletime]
+[section Compile time]
 [endsect]
 
-[section Runtime]
+[section Run time]
 [endsect]
 
 [endsect]
diff --git a/doc/phoenix3.qbk b/doc/phoenix3.qbk
index 99d170e..aca1e08 100644
--- a/doc/phoenix3.qbk
+++ b/doc/phoenix3.qbk
@@ -42,12 +42,13 @@
 [include preface.qbk]
 [include introduction.qbk]
 [include starter_kit.qbk]
+[include advanced.qbk]
 [include reference.qbk]
 
 [/include actors.qbk]
 [/include advanced.qbk]
 [include notes.qbk]
 [include wrap_up.qbk]
-[include acknowledgement.qbk]
+[include acknowledgment.qbk]
 [include references.qbk]
 
diff --git a/doc/reference/bind.qbk b/doc/reference/bind.qbk
index 1b342c5..bd7ece6 100644
--- a/doc/reference/bind.qbk
+++ b/doc/reference/bind.qbk
@@ -19,7 +19,7 @@ is your friend.
 [note Take note that binders are monomorphic. Rather than binding
 functions, the preferred way is to write true generic and polymorphic [link
 phoenix.reference.modules.function lazy-functions]. However, since most of the time we
-are dealing with adaptation of exisiting code, binders get the job done faster.]
+are dealing with adaptation of existing code, binders get the job done faster.]
 
 There is a set of overloaded `bind` template functions. Each `bind(x)`
 function generates a suitable binder object, a [link phoenix.reference.composite
@@ -109,7 +109,7 @@ The object (reference or pointer) can be lazily bound. Examples:
 [section Compatibility with other bind libraries]
 
 `phoenix::bind` passes all testcases of the Boost.Bind library. It is therefore
-completely compatible and interchangable.
+completely compatible and interchangeable.
 
 Note that at the current state of the library, you can not mix phoenix and lambda
 expressions just like that.
diff --git a/doc/reference/composite.qbk b/doc/reference/composite.qbk
index 23ecd53..3385746 100644
--- a/doc/reference/composite.qbk
+++ b/doc/reference/composite.qbk
@@ -38,7 +38,7 @@ The concept of a composite is therefore best formulated in terms of `proto::func
 ]
 
 As mentioned each of the `A0...AN` can be another actor or composite, this makes
-an actor a recursive structure. The actual evluation is handle by the evaluator `F`.
+an actor a recursive structure. The actual evaluation is handle by the evaluator `F`.
 To ease the creation of actors, there exist helper class responsible for
 creating the correct types.
 
diff --git a/doc/reference/concepts.qbk b/doc/reference/concepts.qbk
index 44c04fb..4fd75a8 100644
--- a/doc/reference/concepts.qbk
+++ b/doc/reference/concepts.qbk
@@ -15,110 +15,12 @@
 
 [section Concepts]
 
-[section Environment]
+[/include concepts/expression.qbk]
+[include concepts/actor.qbk]
+[include concepts/evaluator.qbk]
+[include concepts/evaluation_policy.qbk]
+[include concepts/environment.qbk]
 
-[heading Description]
-
-On an actor function call, bafore evaluating the actors expression, the actor
-creates an environment. Basically, the environment packages the arguments in a
-tuple.
-
-[variablelist Notation
-	[[`Env`] [A type fulfilling this concept]]
-	[[`env`] [Object of type Env]]
-	[[`N`] [A __boost_mpl_int__]]
-	[[`M`] [A positive Integer index]]
-]
-
-[heading Valid Expressions]
-
-[table
-	[[Expression] [Return Type] [Runtime Complexity]]
-	[[`get_environment_argument(env)`] [Any Type] [Constant]]
-	[[`get_environment_argument_c(env)`] [Any Type] [Constant]]
-]
-
-[heading Result Type Expressions]
-
-[table
-	[[Expression] [Result Type] [Compiletime Complexity]]
-	[[`result_of::get_environment_argument::type`] [Any Type] [Constant]]
-	[[`result_of::get_environment_argument_c::type`] [Any Type] [Constant]]
-]
-
-[heading Expression Semantics]
-
-[table
-	[[Expression] [Semantics]]
-	[[`get_environment_argument(env)`] [Returns the `N::value`-th argument passed to the enclosed evaluation context]]
-	[[`get_environment_argument_c(env)`] [Returns the `M`th argument passed to the enclosed evaluation context]]
-]
-
-[heading Models]
-
-* [link phoenix.reference.modules.core.basic_environment `boost::phoenix::basic_environment`]
-* [link phoenix.reference.modules.scope.scope_environment `boost::phoenix::scoped_environment`]
-
-[endsect]
-
-[section Actor]
-
-[heading Description]
-
-The Actor is the main concept behind the library.
-
-Actors are TR1 function objects and can accept 0 to `PHOENIX_LIMIT` arguments.
-An Actor is responsible for setting up the __phoenix_concept_environment__ which
-is then passed to the __phoenix_concept_evaluator__.
-Every Actor needs to somehow embed the expression it is supposed to evaluate.
-An Actor itself is required to be a valid Expression.
-
-[note You can set `PHOENIX_LIMIT`, the predefined maximum arity an
-actor can take. By default, `PHOENIX_LIMIT` is set to 10.]
-
-
-[variablelist Notation
-	[[`Actor`]   [A type fulfilling this concept]]
-	[[`actor`]   [Object of type Actor]]
-	[[`A0...AN`] [Argument Types]]
-	[[`a0...aN`] [Objects of type A0, ...AN]]
-	[[`N`] [A __boost_mpl_int__]]
-	[[`M`] [A positive Integer index]]
-]
-
-[heading Valid Expressions]
-
-[table
-	[[Expression] [Return Type] [Runtime Complexity]]
-	[[actor(a0...aN)] [Any Type] [unspecified]]
-	[[element_at(actor)] [Actor] [Constant]]
-	[[element_at_c(actor)] [Actor] [Constant]]
-]
-
-[heading Result Type Expressions]
-[table
-	[[Expression] [Result Type] [Compiletime Complexity]]
-	[[result_of::actor::type] [Any Type] [unspecified]]
-	[[result_of::element_at_c::type] [Any Type] [Constant]]
-	[[result_of::element_at_c::type] [Any Type] [Constant]]
-]
-
-[heading Expression Semantics]
-
-[table
-	[[Expression] [Semantics]]
-	[[actor(a0...aN)] [Evaluates the expression with the default __phoenix_concept_evaluator__]]
-	[[element_at(actor)] [Returns the `N::value`-th element of an compounf expression]]
-	[[element_at_c(actor)] [Returns the `M`th element of an compound expression]]
-]
-
-[heading Models]
-
-* [link phoenix.reference.modules.core.actor `boost::phoenix::actor`]
-* [link phoenix.reference.modules.statement.if_ `boost::phoenix::if_`]
-* [link phoenix.reference.modules.statement.try_ `boost::phoenix::try_`]
-
-[endsect]
 
 [/
 [section Primitive]
@@ -133,92 +35,4 @@ Refinement of Actor.
 [endsect]
 ]
 
-[section EvaluationPolicy]
-
-[heading Description]
-
-Evaluation Policies are the classes which decide how the composite is to be evaluated with respect to the default evaluator.
-
-[variablelist Notation
-   [[`F`] [Type fulfilling this concept]]
-	[[`f`] [Object of type F]]
-	[[`Env`] [A type of __phoenix_concept_environment__]]
-	[[`env`] [Object of type Env]]
-	[[`A0...AN`] [Argument Types]]
-	[[`a0...aN`] [Objects of type A0, ...AN]]
-]
-
-[heading Valid Expressions]
-
-[table
-	[[Expression] [Return Type] [Runtime Complexity]]
-	[[`f(env, a0...aN)`] [Any Type] [unspecified]]
-]
-
-[heading Result Type Expressions]
-[table
-	[[Expression] [Result Type] [Compiletime Complexity]]
-	[[`boost::result_of::type|`] [Result of evaluation] [unspecified]]
-]
-
-[heading Expression Semantics]
-
-[table
-	[[Expression] [Semantics]]
-	[[`f(env, a0...aN)`] [Evalutes the Composite with the given attached data]]
-]
-
-[heading Models]
-
-TODO (almost everything)
-
-[endsect]
-
-[section Evaluator]
-
-[heading Description]
-
-The concepts of evaluators are the working horses behind phoenix.
-They are responsible of evaluating the composed expressions.
-
-Various evaluators are thinkable, the main evaluator will be refered to as the
-default evaluator. It is implemented in terms of the Boost.Proto default context
-and the various __phoenix_concpets_evaluation_policies__.
-
-[variablelist Notation
-	[[`Actor`]   [Type fulfilling this concept]]
-	[[`eval`]    [An object of type Eval]]
-	[[`Expr`]    [Type of the Actor Concept]]
-	[[`expr`]    [Object of type Expr]]
-]
-
-[heading Valid Expressions]
-
-[table
-	[[Expression] [Return Type] [Runtime Complexity]]
-	[[`eval(expr, env)`] [Any Type] [unspecified]]
-]
-
-[heading Result Type Expressions]
-[table
-	[[Expression] [Result Type] [Compiletime Complexity]]
-	[[boost::result_of::type] [Result of evaluation] [unspecified]]
-]
-
-[heading Expression Semantics]
-
-[table
-	[[Expression] [Semantics]]
-	[[`eval(expr, env)`] [Evaluate the expression with the given environment]]
-]
-
-[heading Models]
-
-* eval_grammar
-* arity
-* no_nullary
-* switch_grammar
-
-[endsect]
-
 [endsect]
diff --git a/doc/reference/concepts/actor.qbk b/doc/reference/concepts/actor.qbk
new file mode 100644
index 0000000..4608aae
--- /dev/null
+++ b/doc/reference/concepts/actor.qbk
@@ -0,0 +1,68 @@
+[/==============================================================================
+    Copyright (C) 2001-2010 Joel de Guzman
+    Copyright (C) 2001-2005 Dan Marsden
+    Copyright (C) 2001-2010 Thomas Heller
+
+    Distributed under the Boost Software License, Version 1.0. (See accompanying
+    file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
+===============================================================================/]
+
+[section Actor]
+
+[heading Description]
+
+The Actor is the main concept behind the library.
+
+Actors are TR1 function objects and can accept 0 to `PHOENIX_LIMIT` arguments.
+An Actor is responsible for setting up the __phoenix_concept_environment__ which
+is then passed to the __phoenix_concept_evaluator__.
+Every Actor needs to somehow embed the expression it is supposed to evaluate.
+An Actor itself is required to be a valid Expression.
+
+[note You can set `PHOENIX_LIMIT`, the predefined maximum arity an
+actor can take. By default, `PHOENIX_LIMIT` is set to 10.]
+
+
+[variablelist Notation
+	[[`Actor`]   [A type fulfilling this concept]]
+	[[`actor`]   [Object of type Actor]]
+	[[`A0...AN`] [Argument Types]]
+	[[`a0...aN`] [Objects of type A0, ...AN]]
+	[[`N`] [A __boost_mpl_int__]]
+	[[`M`] [A positive Integer index]]
+]
+
+[heading Valid Expressions]
+
+[table
+	[[Expression] [Return Type] [Run time Complexity]]
+	[[actor(a0...aN)] [Any Type] [unspecified]]
+	[[element_at(actor)] [Actor] [Constant]]
+	[[element_at_c(actor)] [Actor] [Constant]]
+]
+
+[heading Result Type Expressions]
+[table
+	[[Expression] [Result Type] [Compile time Complexity]]
+	[[result_of::actor::type] [Any Type] [unspecified]]
+	[[result_of::element_at_c::type] [Any Type] [Constant]]
+	[[result_of::element_at_c::type] [Any Type] [Constant]]
+]
+
+[heading Expression Semantics]
+
+[table
+	[[Expression] [Semantics]]
+	[[actor(a0...aN)] [Evaluates the expression with the default __phoenix_concept_evaluator__]]
+	[[element_at(actor)] [Returns the `N::value`-th element of an compound expression]]
+	[[element_at_c(actor)] [Returns the `M`th element of an compound expression]]
+]
+
+[heading Models]
+
+* [link phoenix.reference.modules.core.actor `boost::phoenix::actor`]
+* [link phoenix.reference.modules.statement.if__statement `boost::phoenix::if_`]
+* [link phoenix.reference.modules.statement.try__catch__statement `boost::phoenix::try_`]
+
+[endsect]
+
diff --git a/doc/reference/concepts/environment.qbk b/doc/reference/concepts/environment.qbk
new file mode 100644
index 0000000..5db4b8f
--- /dev/null
+++ b/doc/reference/concepts/environment.qbk
@@ -0,0 +1,55 @@
+[/==============================================================================
+    Copyright (C) 2001-2010 Joel de Guzman
+    Copyright (C) 2001-2005 Dan Marsden
+    Copyright (C) 2001-2010 Thomas Heller
+
+    Distributed under the Boost Software License, Version 1.0. (See accompanying
+    file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
+===============================================================================/]
+
+[section Environment]
+
+[heading Description]
+
+On an actor function call, before evaluating the actors expression, the actor
+creates an environment. Basically, the environment packages the arguments in a
+tuple.
+
+[variablelist Notation
+	[[`Env`] [A type fulfilling this concept]]
+	[[`env`] [Object of type Env]]
+	[[`N`] [A __boost_mpl_int__]]
+	[[`M`] [A positive Integer index]]
+]
+
+[heading Valid Expressions]
+
+[table
+	[[Expression] [Return Type] [Runtime Complexity]]
+	[[`get_environment_argument(env)`] [Any Type] [Constant]]
+	[[`get_environment_argument_c(env)`] [Any Type] [Constant]]
+]
+
+[heading Result Type Expressions]
+
+[table
+	[[Expression] [Result Type] [Compiletime Complexity]]
+	[[`result_of::get_environment_argument::type`] [Any Type] [Constant]]
+	[[`result_of::get_environment_argument_c::type`] [Any Type] [Constant]]
+]
+
+[heading Expression Semantics]
+
+[table
+	[[Expression] [Semantics]]
+	[[`get_environment_argument(env)`] [Returns the `N::value`-th argument passed to the enclosed evaluation context]]
+	[[`get_environment_argument_c(env)`] [Returns the `M`th argument passed to the enclosed evaluation context]]
+]
+
+[heading Models]
+
+* [link phoenix.reference.modules.core.basic_environment `boost::phoenix::basic_environment`]
+* [link phoenix.reference.modules.scope.scope_environment `boost::phoenix::scoped_environment`]
+
+[endsect]
+
diff --git a/doc/reference/concepts/evaluation_policy.qbk b/doc/reference/concepts/evaluation_policy.qbk
new file mode 100644
index 0000000..31194f7
--- /dev/null
+++ b/doc/reference/concepts/evaluation_policy.qbk
@@ -0,0 +1,49 @@
+[/==============================================================================
+    Copyright (C) 2001-2010 Joel de Guzman
+    Copyright (C) 2001-2005 Dan Marsden
+    Copyright (C) 2001-2010 Thomas Heller
+
+    Distributed under the Boost Software License, Version 1.0. (See accompanying
+    file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
+===============================================================================/]
+
+[section EvaluationPolicy]
+
+[heading Description]
+
+Evaluation Policies are the classes which decide how the composite is to be evaluated with respect to the default evaluator.
+
+[variablelist Notation
+   [[`F`] [Type fulfilling this concept]]
+	[[`f`] [Object of type F]]
+	[[`Env`] [A type of __phoenix_concept_environment__]]
+	[[`env`] [Object of type Env]]
+	[[`A0...AN`] [Argument Types]]
+	[[`a0...aN`] [Objects of type A0, ...AN]]
+]
+
+[heading Valid Expressions]
+
+[table
+	[[Expression] [Return Type] [Run time Complexity]]
+	[[`f(env, a0...aN)`] [Any Type] [unspecified]]
+]
+
+[heading Result Type Expressions]
+[table
+	[[Expression] [Result Type] [Compile time Complexity]]
+	[[`boost::result_of::type|`] [Result of evaluation] [unspecified]]
+]
+
+[heading Expression Semantics]
+
+[table
+	[[Expression] [Semantics]]
+	[[`f(env, a0...aN)`] [Evaluates the Composite with the given attached data]]
+]
+
+[heading Models]
+
+TODO (almost everything)
+
+[endsect]
diff --git a/doc/reference/concepts/evaluator.qbk b/doc/reference/concepts/evaluator.qbk
new file mode 100644
index 0000000..6f72304
--- /dev/null
+++ b/doc/reference/concepts/evaluator.qbk
@@ -0,0 +1,58 @@
+[/==============================================================================
+    Copyright (C) 2001-2010 Joel de Guzman
+    Copyright (C) 2001-2005 Dan Marsden
+    Copyright (C) 2001-2010 Thomas Heller
+
+    Distributed under the Boost Software License, Version 1.0. (See accompanying
+    file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
+===============================================================================/]
+
+[section Evaluator]
+
+[heading Description]
+
+The concepts of evaluators are the working horses behind phoenix.
+They are responsible of evaluating the composed expressions.
+
+Various evaluators are thinkable, the main evaluator will be referred to as the
+default evaluator. It is implemented in terms of the Boost.Proto default context
+and the various __phoenix_concepts_evaluation_policies__.
+
+[variablelist Notation
+	[[`Eval`]    [Type fulfilling this concept]]
+	[[`eval`]    [An object of type Eval]]
+	[[`Expr`]    [Type of the Actor Concept]]
+	[[`expr`]    [Object of type Expr]]
+	[[`Env`]     [Type fulfilling the Environment concept]]
+	[[`env`]     [Object of type Env]]
+]
+
+[heading Valid Expressions]
+
+[table
+	[[Expression] [Return Type] [Run time Complexity]]
+	[[`eval(expr, env)`] [Any Type] [unspecified]]
+]
+
+[heading Result Type Expressions]
+[table
+	[[Expression] [Result Type] [Compile time Complexity]]
+	[[boost::result_of::type] [Result of evaluation] [unspecified]]
+]
+
+[heading Expression Semantics]
+
+[table
+	[[Expression] [Semantics]]
+	[[`eval(expr, env)`] [Evaluate the expression with the given environment]]
+]
+
+[heading Models]
+
+* eval_grammar
+* arity
+* no_nullary
+* switch_grammar
+
+[endsect]
+
diff --git a/doc/reference/concepts/expression.qbk b/doc/reference/concepts/expression.qbk
new file mode 100644
index 0000000..3097d1c
--- /dev/null
+++ b/doc/reference/concepts/expression.qbk
@@ -0,0 +1,41 @@
+[/==============================================================================
+    Copyright (C) 2001-2010 Joel de Guzman
+    Copyright (C) 2001-2005 Dan Marsden
+    Copyright (C) 2001-2010 Thomas Heller
+
+    Distributed under the Boost Software License, Version 1.0. (See accompanying
+    file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
+===============================================================================/]
+
+[section Expression]
+
+[heading Description]
+
+An expression is considered the most general concept behind phoenix.
+
+All in all, everything can be an expression
+
+[variablelist Notation
+]
+
+[heading Valid Expressions]
+
+[table
+	[[Expression] [Return Type] [Run time Complexity]]
+]
+
+[heading Result Type Expressions]
+[table
+	[[Expression] [Result Type] [Compile time Complexity]]
+]
+
+[heading Expression Semantics]
+
+[table
+	[[Expression] [Semantics]]
+]
+
+[heading Models]
+
+[endsect]
+
diff --git a/doc/reference/core.qbk b/doc/reference/core.qbk
index d3dd329..1379f26 100644
--- a/doc/reference/core.qbk
+++ b/doc/reference/core.qbk
@@ -141,7 +141,7 @@ placeholder index. By default, `PHOENIX_ARG_LIMIT` is set to `PHOENIX_LIMIT`
 You see the use make_argument this is a convenience class wrapping the `compose` class:
 
     template 
-    struct make_arguemnt : compose {};
+    struct make_argument : compose {};
 
 This scheme of actor creation is used throughout the library and follows the DRY principle.
 See [link phoenix.reference.composite Composites] for more details.
@@ -161,10 +161,10 @@ which is equivalent to:
     add(arg1, 6)
 
 [note
-When dealing with argument placeholders the question arises wether you can call
+When dealing with argument placeholders the question arises whether you can call
 member functions on an `argument` actor.
 
-This is possible by supplying a costum `actor` which has a member
+This is possible by supplying a custom `actor` which has a member
 generator function. See [link phoenix.advanced.extending.extending_actors Extending Actors]
 for more details.
 ]
@@ -216,7 +216,7 @@ Here, arguments b, c, and d are ignored. The function `add` takes in the first
 argument (`arg1`) and the fifth argument (`arg5`).
 
 [note There are a few reasons why enforcing strict arity is not
-desireable. A case in point is the callback function. Typical callback functions
+desirable. A case in point is the callback function. Typical callback functions
 provide more information than is actually needed. Lambda functions are often
 used as callbacks.]
 
diff --git a/doc/reference/function.qbk b/doc/reference/function.qbk
index 3dfcb32..6b32e6a 100644
--- a/doc/reference/function.qbk
+++ b/doc/reference/function.qbk
@@ -57,7 +57,7 @@ lazy factorial function:
 (See [@../../example/users_manual/factorial.cpp factorial.cpp])
 
 [note The type of Arg is either a const-reference or non-const-reference
-(depending on wether your argument to the actor evaluation is a const-ref or
+(depending on whether your argument to the actor evaluation is a const-ref or
 non-const-ref).]
 
 Having implemented the `factorial_impl` type, we can declare and instantiate a lazy
diff --git a/doc/reference/object.qbk b/doc/reference/object.qbk
index f84eb55..235bd46 100644
--- a/doc/reference/object.qbk
+++ b/doc/reference/object.qbk
@@ -30,7 +30,7 @@ Lazily construct an object from an arbitrary set of arguments:
 
     construct(ctor_arg1, ctor_arg2, ..., ctor_argN);
 
-where the given parameters are the parameters to the contructor of the object of
+where the given parameters are the parameters to the constructor of the object of
 type T (This implies, that type T is expected to have a constructor with a
 corresponding set of parameter types.).
 
@@ -53,7 +53,7 @@ Lazily construct an object, on the heap, from an arbitrary set of arguments:
 
     new_(ctor_arg1, ctor_arg2, ..., ctor_argN);
 
-where the given parameters are the parameters to the contructor of the object of
+where the given parameters are the parameters to the contractor of the object of
 type T (This implies, that type T is expected to have a constructor with a
 corresponding set of parameter types.).
 
diff --git a/doc/reference/operator.qbk b/doc/reference/operator.qbk
index 1d3dd08..4636b35 100644
--- a/doc/reference/operator.qbk
+++ b/doc/reference/operator.qbk
@@ -53,8 +53,8 @@ Operator expressions are lazily evaluated following four simple rules:
 # A binary operator, except `->*` will be lazily evaluated when
   /at least/ one of its operands is an actor object
   (see [link phoenix.reference.actor actors]).
-# Unary operators are lazily evaluted if their argument is an actor object.
-# Operator `->*` is lazily evaluted if the left hand argument is an actor object.
+# Unary operators are lazily evaluated if their argument is an actor object.
+# Operator `->*` is lazily evaluated if the left hand argument is an actor object.
 # The result of a lazy operator is an actor object that can in turn allow the
   applications of rules 1, 2 and 3.
 
diff --git a/doc/reference/organisation.qbk b/doc/reference/organisation.qbk
index 99763cf..b3a70fb 100644
--- a/doc/reference/organisation.qbk
+++ b/doc/reference/organisation.qbk
@@ -20,7 +20,7 @@ The modules are orthogonal, with no cyclic dependencies.
 Lower layers do not depend on higher layers. Modules in a layer do not depend on other modules in the same layer.
 This means, for example, that Bind can be completely discarded if it is
 not required; or one could perhaps take out Operator and Statement and just use Function,
-which may be desireable in a pure FP application.
+which may be desirable in a pure FP application.
 
 The library has grown from the original Phoenix but still comprises only
 header files. There are no object files to link against.
@@ -47,7 +47,7 @@ again be another composite.
     [[Module]           [Description]]
     [[Function]         [Lazy functions support (e.g. `add`)]]
     [[Operator]         [Lazy operators support (e.g. `+`)]]
-    [[Statement]        [Lazy statments (e.g. `if_`, `while_`)]]
+    [[Statement]        [Lazy statements (e.g. `if_`, `while_`)]]
     [[Object]           [Lazy casts (e.g. `static_cast_`),
                         object creation destruction (e.g.
                         `new_`, `delete_`)]]
diff --git a/doc/reference/statement.qbk b/doc/reference/statement.qbk
index ef7cc46..c795eca 100644
--- a/doc/reference/statement.qbk
+++ b/doc/reference/statement.qbk
@@ -327,17 +327,17 @@ prints messages about different exception types it catches.
     #include 
 
 As a natural companion to the try/catch support, the statement module provides
-lazy throwing and rethrowing of exceptions.
+lazy throwing and re-throwing of exceptions.
 
 The syntax to throw an exception is:
 
     throw_(exception_expression)
 
-The syntax to rethrow an exception is:
+The syntax to re-throw an exception is:
 
     throw_()
 
-Example: This code extends the try/catch example, rethrowing exceptions derived from
+Example: This code extends the try/catch example, re-throwing exceptions derived from
 runtime_error or exception, and translating other exception types to runtime_errors.
 
     try_
diff --git a/doc/starter_kit/references.qbk b/doc/starter_kit/references.qbk
index df0c213..54e4f7c 100644
--- a/doc/starter_kit/references.qbk
+++ b/doc/starter_kit/references.qbk
@@ -9,7 +9,7 @@
 
 [section References]
 
-References are functions. They hold a reference to a value stored somehere.
+References are functions. They hold a reference to a value stored somewhere.
 For example, given:
 
     int i = 3;
diff --git a/doc/wrap_up.qbk b/doc/wrap_up.qbk
index 3deebc1..dac5064 100644
--- a/doc/wrap_up.qbk
+++ b/doc/wrap_up.qbk
@@ -15,7 +15,7 @@ mainstream. In as much as structured programming of the 70s and object oriented
 programming in the 80s and generic programming in the 90s shaped our thoughts
 towards a more robust sense of software engineering, FP will certainly be a
 paradigm that will catapult us towards more powerful software design and
-engineering onward into the new millenium.
+engineering onward into the new millennium.
 
 Let me quote Doug Gregor of Boost.org. About functional style programming
 libraries:
diff --git a/example/container_actor.cpp b/example/container_actor.cpp
new file mode 100644
index 0000000..392509d
--- /dev/null
+++ b/example/container_actor.cpp
@@ -0,0 +1,91 @@
+/*==============================================================================
+    Copyright (c) 2005-2010 Joel de Guzman
+    Copyright (c) 2010 Thomas Heller
+
+    Distributed under the Boost Software License, Version 1.0. (See accompanying
+    file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
+==============================================================================*/
+
+#include 
+#include 
+
+#include 
+
+namespace phoenix = boost::phoenix;
+
+using phoenix::actor;
+using phoenix::function;
+using phoenix::arg_names::arg1;
+
+struct size_impl
+{
+    // result_of protocol:
+    template 
+    struct result;
+    
+    template 
+    struct result
+    {
+        // Note, remove reference here, because Container can be anything
+        typedef typename boost::remove_reference::type container_type;
+        
+        // The result will be size_type
+        typedef typename container_type::size_type type;
+    };
+    
+    template 
+    typename result::type
+    operator()(Container const& container) const
+    {
+        return container.size();
+    }
+};
+
+template 
+struct container_actor
+    : actor
+{
+    typedef actor base_type;
+    typedef container_actor that_type;
+
+    container_actor( base_type const& base )
+        : base_type( base ) {}
+
+    typename phoenix::result_of::function::type const
+    size() const
+    {
+        function const f = size_impl();
+        return f(*this);
+    }
+
+    // the rest ...
+};
+
+
+template 
+container_actor const
+container( actor const& expr )
+{
+    return expr;
+}
+
+
+template 
+struct make_container_argument : phoenix::compose_ex {};
+
+typedef make_container_argument > make_con1;
+make_con1::type const con1 = make_con1()(boost::mpl::int_<0>());
+
+int main()
+{
+    std::vector v;
+    v.push_back(0);
+    v.push_back(1);
+    v.push_back(2);
+    v.push_back(3);
+    
+    std::cout << (container(arg1).size())(v) << " == " << v.size() << "\n";
+
+
+    std::cout << (con1.size())(v) << " == " << v.size() << "\n";
+}
diff --git a/test/core/function_composition.cpp b/test/core/function_composition.cpp
index 46ea0b0..209d1d0 100644
--- a/test/core/function_composition.cpp
+++ b/test/core/function_composition.cpp
@@ -34,5 +34,8 @@ int main()
 
 	BOOST_TEST((arg1 + arg2)(arg1, arg1)(8) == 16);
 
+    double mean = 8.0;
+    (arg1 + arg2 * (arg1 * arg1)( boost::phoenix::val(1.0) - mean ))(1.0, 2.0);
+
 	return boost::report_errors();
 }