|
|
Boost-Commit : |
Subject: [Boost-commit] svn:boost r76056 - in branches/release: . boost boost/algorithm/string boost/archive boost/bimap boost/config boost/date_time boost/date_time/posix_time boost/detail boost/dynamic_bitset boost/filesystem boost/function boost/functional boost/fusion boost/geometry boost/geometry/algorithms boost/geometry/arithmetic boost/geometry/core boost/geometry/domains boost/geometry/geometries boost/geometry/iterators boost/geometry/multi boost/geometry/policies boost/geometry/strategies boost/geometry/util boost/geometry/views boost/gil boost/graph boost/heap boost/icl boost/integer boost/interprocess boost/intrusive boost/io boost/iostreams boost/iterator boost/locale boost/math boost/math/special_functions boost/msm boost/msm/back boost/msm/front boost/msm/front/detail boost/msm/front/euml boost/msm/mpl_graph boost/numeric/ublas boost/pool boost/preprocessor boost/program_options boost/program_options/detail boost/property_tree boost/proto boost/python boost/range boost/regex boost/serialization boost/signals boost/signals2 boost/spirit boost/spirit/home boost/spirit/home/karma boost/spirit/home/support boost/statechart boost/system boost/thread boost/tr1 boost/type_traits boost/typeof boost/unordered boost/utility boost/uuid boost/variant boost/wave boost/xpressive doc libs libs/algorithm/string libs/array libs/array/test libs/bimap libs/config libs/date_time libs/date_time/data libs/date_time/example/gregorian libs/date_time/example/local_time libs/date_time/example/posix_time libs/date_time/example/tutorial libs/date_time/test/posix_time libs/date_time/xmldoc libs/detail libs/filesystem libs/function libs/functional libs/fusion libs/geometry libs/geometry/doc libs/geometry/doc/concept libs/geometry/doc/doxy libs/geometry/doc/generated libs/geometry/doc/html libs/geometry/doc/reference libs/geometry/doc/src libs/geometry/example libs/geometry/test libs/graph/doc libs/graph_parallel libs/icl libs/icl/doc libs/icl/doc/html libs/icl/doc/html/header/boost/icl libs/icl/test libs/icl/test/test_doc_code_ libs/integer libs/interprocess libs/intrusive libs/io libs/io/doc libs/iostreams libs/iterator libs/locale libs/locale/src libs/math libs/math/doc/sf_and_dist libs/math/doc/sf_and_dist/html/math_toolkit/main_overview libs/math/test libs/mpi/build libs/mpl/doc/refmanual libs/mpl/doc/src/refmanual libs/msm libs/numeric/ublas libs/numeric/ublas/doc libs/parameter/doc/html libs/phoenix/doc libs/phoenix/doc/examples libs/pool libs/preprocessor libs/program_options libs/program_options/test libs/property_tree libs/proto/doc libs/proto/doc/reference libs/proto/example libs/python libs/range libs/regex libs/serialization libs/serialization/example libs/serialization/src libs/serialization/test libs/signals libs/signals2 libs/signals2/doc libs/spirit libs/spirit/classic/example libs/spirit/doc libs/spirit/example libs/spirit/phoenix libs/spirit/test libs/spirit/test/qi libs/statechart libs/static_assert libs/system libs/thread libs/timer libs/tr1 libs/type_traits libs/typeof/doc libs/unordered libs/utility libs/utility/swap/test libs/uuid libs/wave more status tools tools/bcp tools/boostbook tools/build/v2 tools/build/v2/tools tools/inspect tools/quickbook tools/regression tools/regression/src tools/release tools/wave
From: eric_at_[hidden]
Date: 2011-12-18 19:32:20
Author: eric_niebler
Date: 2011-12-18 19:32:18 EST (Sun, 18 Dec 2011)
New Revision: 76056
URL: http://svn.boost.org/trac/boost/changeset/76056
Log:
merged doc and example changes from trunk
Added:
branches/release/libs/proto/example/external_transforms.cpp
- copied unchanged from r76055, /trunk/libs/proto/example/external_transforms.cpp
Properties modified:
branches/release/ (props changed)
branches/release/INSTALL (props changed)
branches/release/Jamroot (props changed)
branches/release/LICENSE_1_0.txt (props changed)
branches/release/boost/ (props changed)
branches/release/boost-build.jam (props changed)
branches/release/boost.css (props changed)
branches/release/boost.png (props changed)
branches/release/boost/algorithm/string/ (props changed)
branches/release/boost/archive/ (props changed)
branches/release/boost/array.hpp (props changed)
branches/release/boost/bimap/ (props changed)
branches/release/boost/concept_check.hpp (props changed)
branches/release/boost/config/ (props changed)
branches/release/boost/config.hpp (props changed)
branches/release/boost/cregex.hpp (props changed)
branches/release/boost/cstdint.hpp (props changed)
branches/release/boost/current_function.hpp (props changed)
branches/release/boost/date_time/c_time.hpp (props changed)
branches/release/boost/date_time/date_formatting.hpp (props changed)
branches/release/boost/date_time/filetime_functions.hpp (props changed)
branches/release/boost/date_time/gregorian_calendar.ipp (props changed)
branches/release/boost/date_time/posix_time/time_serialize.hpp (props changed)
branches/release/boost/date_time/strings_from_facet.hpp (props changed)
branches/release/boost/date_time/time_facet.hpp (props changed)
branches/release/boost/date_time/tz_db_base.hpp (props changed)
branches/release/boost/detail/ (props changed)
branches/release/boost/detail/interlocked.hpp (props changed)
branches/release/boost/dynamic_bitset/dynamic_bitset.hpp (props changed)
branches/release/boost/filesystem/ (props changed)
branches/release/boost/filesystem.hpp (props changed)
branches/release/boost/function/ (props changed)
branches/release/boost/function/function_template.hpp (props changed)
branches/release/boost/functional/ (props changed)
branches/release/boost/fusion/ (props changed)
branches/release/boost/geometry/ (props changed)
branches/release/boost/geometry/algorithms/ (props changed)
branches/release/boost/geometry/arithmetic/ (props changed)
branches/release/boost/geometry/core/ (props changed)
branches/release/boost/geometry/domains/ (props changed)
branches/release/boost/geometry/geometries/ (props changed)
branches/release/boost/geometry/geometry.hpp (props changed)
branches/release/boost/geometry/iterators/ (props changed)
branches/release/boost/geometry/multi/ (props changed)
branches/release/boost/geometry/policies/ (props changed)
branches/release/boost/geometry/strategies/ (props changed)
branches/release/boost/geometry/util/ (props changed)
branches/release/boost/geometry/views/ (props changed)
branches/release/boost/gil/ (props changed)
branches/release/boost/graph/ (props changed)
branches/release/boost/heap/ (props changed)
branches/release/boost/icl/ (props changed)
branches/release/boost/integer/ (props changed)
branches/release/boost/integer.hpp (props changed)
branches/release/boost/integer_fwd.hpp (props changed)
branches/release/boost/integer_traits.hpp (props changed)
branches/release/boost/interprocess/ (props changed)
branches/release/boost/intrusive/ (props changed)
branches/release/boost/io/ (props changed)
branches/release/boost/iostreams/ (props changed)
branches/release/boost/iterator/ (props changed)
branches/release/boost/iterator/iterator_facade.hpp (props changed)
branches/release/boost/locale/ (props changed)
branches/release/boost/locale.hpp (props changed)
branches/release/boost/math/ (props changed)
branches/release/boost/math/special_functions/ (props changed)
branches/release/boost/math_fwd.hpp (props changed)
branches/release/boost/msm/ (props changed)
branches/release/boost/msm/active_state_switching_policies.hpp (props changed)
branches/release/boost/msm/back/ (props changed)
branches/release/boost/msm/back/args.hpp (props changed)
branches/release/boost/msm/back/bind_helpers.hpp (props changed)
branches/release/boost/msm/back/common_types.hpp (props changed)
branches/release/boost/msm/back/copy_policies.hpp (props changed)
branches/release/boost/msm/back/default_compile_policy.hpp (props changed)
branches/release/boost/msm/back/dispatch_table.hpp (props changed)
branches/release/boost/msm/back/favor_compile_time.hpp (props changed)
branches/release/boost/msm/back/fold_to_list.hpp (props changed)
branches/release/boost/msm/back/history_policies.hpp (props changed)
branches/release/boost/msm/back/metafunctions.hpp (props changed)
branches/release/boost/msm/back/mpl_graph_fsm_check.hpp (props changed)
branches/release/boost/msm/back/no_fsm_check.hpp (props changed)
branches/release/boost/msm/back/queue_container_circular.hpp (props changed)
branches/release/boost/msm/back/queue_container_deque.hpp (props changed)
branches/release/boost/msm/back/state_machine.hpp (props changed)
branches/release/boost/msm/back/tools.hpp (props changed)
branches/release/boost/msm/common.hpp (props changed)
branches/release/boost/msm/front/ (props changed)
branches/release/boost/msm/front/common_states.hpp (props changed)
branches/release/boost/msm/front/completion_event.hpp (props changed)
branches/release/boost/msm/front/detail/ (props changed)
branches/release/boost/msm/front/detail/common_states.hpp (props changed)
branches/release/boost/msm/front/detail/row2_helper.hpp (props changed)
branches/release/boost/msm/front/euml/ (props changed)
branches/release/boost/msm/front/euml/algorithm.hpp (props changed)
branches/release/boost/msm/front/euml/common.hpp (props changed)
branches/release/boost/msm/front/euml/container.hpp (props changed)
branches/release/boost/msm/front/euml/euml.hpp (props changed)
branches/release/boost/msm/front/euml/euml_typeof.hpp (props changed)
branches/release/boost/msm/front/euml/guard_grammar.hpp (props changed)
branches/release/boost/msm/front/euml/iteration.hpp (props changed)
branches/release/boost/msm/front/euml/operator.hpp (props changed)
branches/release/boost/msm/front/euml/phoenix_placeholders.hpp (props changed)
branches/release/boost/msm/front/euml/querying.hpp (props changed)
branches/release/boost/msm/front/euml/state_grammar.hpp (props changed)
branches/release/boost/msm/front/euml/stl.hpp (props changed)
branches/release/boost/msm/front/euml/stt_grammar.hpp (props changed)
branches/release/boost/msm/front/euml/transformation.hpp (props changed)
branches/release/boost/msm/front/functor_row.hpp (props changed)
branches/release/boost/msm/front/internal_row.hpp (props changed)
branches/release/boost/msm/front/row2.hpp (props changed)
branches/release/boost/msm/front/state_machine_def.hpp (props changed)
branches/release/boost/msm/front/states.hpp (props changed)
branches/release/boost/msm/mpl_graph/ (props changed)
branches/release/boost/msm/msm_grammar.hpp (props changed)
branches/release/boost/msm/proto_config.hpp (props changed)
branches/release/boost/msm/row_tags.hpp (props changed)
branches/release/boost/numeric/ublas/ (props changed)
branches/release/boost/numeric/ublas/functional.hpp (props changed)
branches/release/boost/pool/ (props changed)
branches/release/boost/preprocessor/ (props changed)
branches/release/boost/program_options/ (props changed)
branches/release/boost/program_options/detail/parsers.hpp (props changed)
branches/release/boost/program_options/parsers.hpp (props changed)
branches/release/boost/property_tree/ (props changed)
branches/release/boost/python/ (props changed)
branches/release/boost/range/ (props changed)
branches/release/boost/regex/ (props changed)
branches/release/boost/regex.h (props changed)
branches/release/boost/regex.hpp (props changed)
branches/release/boost/regex_fwd.hpp (props changed)
branches/release/boost/serialization/ (props changed)
branches/release/boost/signals/ (props changed)
branches/release/boost/signals2/ (props changed)
branches/release/boost/signals2.hpp (props changed)
branches/release/boost/spirit/ (props changed)
branches/release/boost/spirit/home/ (props changed)
branches/release/boost/spirit/home/karma/ (props changed)
branches/release/boost/spirit/home/support/attributes.hpp (props changed)
branches/release/boost/statechart/ (props changed)
branches/release/boost/static_assert.hpp (props changed)
branches/release/boost/system/ (props changed)
branches/release/boost/thread/ (props changed)
branches/release/boost/thread.hpp (props changed)
branches/release/boost/timer.hpp (props changed)
branches/release/boost/token_functions.hpp (props changed)
branches/release/boost/tr1/ (props changed)
branches/release/boost/type_traits/ (props changed)
branches/release/boost/type_traits.hpp (props changed)
branches/release/boost/typeof/message.hpp (props changed)
branches/release/boost/typeof/register_functions.hpp (props changed)
branches/release/boost/typeof/register_functions_iterate.hpp (props changed)
branches/release/boost/typeof/typeof.hpp (props changed)
branches/release/boost/typeof/unsupported.hpp (props changed)
branches/release/boost/unordered/ (props changed)
branches/release/boost/utility/ (props changed)
branches/release/boost/utility/value_init.hpp (props changed)
branches/release/boost/uuid/ (props changed)
branches/release/boost/variant/ (props changed)
branches/release/boost/version.hpp (props changed)
branches/release/boost/wave/ (props changed)
branches/release/boost/xpressive/ (props changed)
branches/release/boostcpp.jam (props changed)
branches/release/bootstrap.bat (props changed)
branches/release/bootstrap.sh (props changed)
branches/release/doc/ (props changed)
branches/release/index.htm (props changed)
branches/release/index.html (props changed)
branches/release/libs/ (props changed)
branches/release/libs/algorithm/string/ (props changed)
branches/release/libs/array/ (props changed)
branches/release/libs/array/test/array0.cpp (props changed)
branches/release/libs/array/test/array2.cpp (props changed)
branches/release/libs/array/test/array6.cpp (props changed)
branches/release/libs/bimap/ (props changed)
branches/release/libs/config/ (props changed)
branches/release/libs/date_time/ (props changed)
branches/release/libs/date_time/data/date_time_zonespec.csv (props changed)
branches/release/libs/date_time/example/gregorian/days_between_new_years.cpp (props changed)
branches/release/libs/date_time/example/gregorian/days_since_year_start.cpp (props changed)
branches/release/libs/date_time/example/gregorian/days_till_new_year.cpp (props changed)
branches/release/libs/date_time/example/gregorian/month_add.cpp (props changed)
branches/release/libs/date_time/example/local_time/flight.cpp (props changed)
branches/release/libs/date_time/example/local_time/local_date_time.cpp (props changed)
branches/release/libs/date_time/example/posix_time/print_hours.cpp (props changed)
branches/release/libs/date_time/example/posix_time/time_math.cpp (props changed)
branches/release/libs/date_time/example/tutorial/io_tutorial.cpp (props changed)
branches/release/libs/date_time/test/posix_time/testtime_facet.cpp (props changed)
branches/release/libs/date_time/test/posix_time/testtime_input_facet.cpp (props changed)
branches/release/libs/date_time/xmldoc/date_class.xml (props changed)
branches/release/libs/date_time/xmldoc/usage_examples.xml (props changed)
branches/release/libs/detail/ (props changed)
branches/release/libs/filesystem/ (props changed)
branches/release/libs/function/ (props changed)
branches/release/libs/functional/ (props changed)
branches/release/libs/fusion/ (props changed)
branches/release/libs/geometry/ (props changed)
branches/release/libs/geometry/doc/ (props changed)
branches/release/libs/geometry/doc/Jamfile.v2 (props changed)
branches/release/libs/geometry/doc/about_documentation.qbk (props changed)
branches/release/libs/geometry/doc/acknowledgments.qbk (props changed)
branches/release/libs/geometry/doc/compiling.qbk (props changed)
branches/release/libs/geometry/doc/concept/ (props changed)
branches/release/libs/geometry/doc/copyright_note_policy.txt (props changed)
branches/release/libs/geometry/doc/design_rationale.qbk (props changed)
branches/release/libs/geometry/doc/doxy/ (props changed)
branches/release/libs/geometry/doc/generated/ (props changed)
branches/release/libs/geometry/doc/geometry.qbk (props changed)
branches/release/libs/geometry/doc/html/ (props changed)
branches/release/libs/geometry/doc/imports.qbk (props changed)
branches/release/libs/geometry/doc/introduction.qbk (props changed)
branches/release/libs/geometry/doc/make_qbk.py (props changed)
branches/release/libs/geometry/doc/matrix.qbk (props changed)
branches/release/libs/geometry/doc/quickref.xml (props changed)
branches/release/libs/geometry/doc/quickstart.qbk (props changed)
branches/release/libs/geometry/doc/readme.txt (props changed)
branches/release/libs/geometry/doc/reference/ (props changed)
branches/release/libs/geometry/doc/reference.qbk (props changed)
branches/release/libs/geometry/doc/src/ (props changed)
branches/release/libs/geometry/example/ (props changed)
branches/release/libs/geometry/index.html (props changed)
branches/release/libs/geometry/test/ (props changed)
branches/release/libs/graph/doc/ (props changed)
branches/release/libs/graph_parallel/ (props changed)
branches/release/libs/icl/ (props changed)
branches/release/libs/icl/doc/ (props changed)
branches/release/libs/icl/doc/html/ (props changed)
branches/release/libs/icl/doc/html/header/boost/icl/ (props changed)
branches/release/libs/icl/test/ (props changed)
branches/release/libs/icl/test/test_doc_code_/ (props changed)
branches/release/libs/integer/ (props changed)
branches/release/libs/interprocess/ (props changed)
branches/release/libs/intrusive/ (props changed)
branches/release/libs/io/ (props changed)
branches/release/libs/io/doc/ (props changed)
branches/release/libs/iostreams/ (props changed)
branches/release/libs/iterator/ (props changed)
branches/release/libs/libraries.htm (props changed)
branches/release/libs/locale/ (props changed)
branches/release/libs/locale/src/ (props changed)
branches/release/libs/maintainers.txt (props changed)
branches/release/libs/math/ (props changed)
branches/release/libs/math/doc/sf_and_dist/faq.qbk (props changed)
branches/release/libs/math/doc/sf_and_dist/html/math_toolkit/main_overview/faq.html (props changed)
branches/release/libs/math/test/s_.ipp (props changed)
branches/release/libs/mpi/build/ (props changed)
branches/release/libs/mpl/doc/refmanual/broken-compiler-workarounds.html (props changed)
branches/release/libs/mpl/doc/refmanual/categorized-index-concepts.html (props changed)
branches/release/libs/mpl/doc/refmanual/cfg-no-preprocessed-headers.html (props changed)
branches/release/libs/mpl/doc/refmanual/composition-and-argument-binding.html (props changed)
branches/release/libs/mpl/doc/refmanual/data-types-concepts.html (props changed)
branches/release/libs/mpl/doc/refmanual/data-types-miscellaneous.html (props changed)
branches/release/libs/mpl/doc/refmanual/extensible-associative-sequence.html (props changed)
branches/release/libs/mpl/doc/refmanual/inserter-class.html (props changed)
branches/release/libs/mpl/doc/refmanual/tag-dispatched-metafunction.html (props changed)
branches/release/libs/mpl/doc/refmanual/trivial-metafunctions-summary.html (props changed)
branches/release/libs/mpl/doc/src/refmanual/Iterators-Iterator.rst (props changed)
branches/release/libs/msm/ (props changed)
branches/release/libs/numeric/ublas/ (props changed)
branches/release/libs/numeric/ublas/doc/ (props changed)
branches/release/libs/parameter/doc/html/index.html (props changed)
branches/release/libs/phoenix/doc/basics.qbk (props changed)
branches/release/libs/phoenix/doc/examples/extending_actors.qbk (props changed)
branches/release/libs/phoenix/doc/organisation.qbk (props changed)
branches/release/libs/pool/ (props changed)
branches/release/libs/preprocessor/ (props changed)
branches/release/libs/program_options/ (props changed)
branches/release/libs/program_options/test/parsers_test.cpp (props changed)
branches/release/libs/property_tree/ (props changed)
branches/release/libs/python/ (props changed)
branches/release/libs/range/ (props changed)
branches/release/libs/regex/ (props changed)
branches/release/libs/serialization/ (props changed)
branches/release/libs/serialization/example/ (props changed)
branches/release/libs/serialization/src/ (props changed)
branches/release/libs/serialization/test/test_diamond_complex.cpp (props changed)
branches/release/libs/signals/ (props changed)
branches/release/libs/signals2/ (props changed)
branches/release/libs/signals2/doc/ (props changed)
branches/release/libs/spirit/ (props changed)
branches/release/libs/spirit/classic/example/ (props changed)
branches/release/libs/spirit/doc/ (props changed)
branches/release/libs/spirit/example/ (props changed)
branches/release/libs/spirit/phoenix/ (props changed)
branches/release/libs/spirit/test/ (props changed)
branches/release/libs/spirit/test/qi/optional.cpp (props changed)
branches/release/libs/statechart/ (props changed)
branches/release/libs/static_assert/ (props changed)
branches/release/libs/system/ (props changed)
branches/release/libs/thread/ (props changed)
branches/release/libs/timer/ (props changed)
branches/release/libs/tr1/ (props changed)
branches/release/libs/type_traits/ (props changed)
branches/release/libs/typeof/doc/typeof.qbk (props changed)
branches/release/libs/unordered/ (props changed)
branches/release/libs/utility/ (props changed)
branches/release/libs/utility/assert.html (props changed)
branches/release/libs/utility/assert_test.cpp (props changed)
branches/release/libs/utility/swap.html (props changed)
branches/release/libs/utility/swap/test/std_bitset.cpp (props changed)
branches/release/libs/utility/value_init.htm (props changed)
branches/release/libs/utility/value_init_test.cpp (props changed)
branches/release/libs/uuid/ (props changed)
branches/release/libs/wave/ (props changed)
branches/release/more/ (props changed)
branches/release/rst.css (props changed)
branches/release/status/ (props changed)
branches/release/status/Jamfile.v2 (props changed)
branches/release/status/expected_results.xml (props changed)
branches/release/status/explicit-failures-markup.xml (props changed)
branches/release/status/explicit-failures.xsd (props changed)
branches/release/tools/ (props changed)
branches/release/tools/bcp/ (props changed)
branches/release/tools/boostbook/ (props changed)
branches/release/tools/build/v2/ (props changed)
branches/release/tools/build/v2/tools/mpi.jam (props changed)
branches/release/tools/inspect/ (props changed)
branches/release/tools/quickbook/ (props changed)
branches/release/tools/regression/ (props changed)
branches/release/tools/regression/src/library_status.cpp (props changed)
branches/release/tools/release/ (props changed)
branches/release/tools/wave/ (props changed)
Text files modified:
branches/release/boost/proto/repeat.hpp | 10 +-
branches/release/libs/proto/doc/back_end.qbk | 176 +++++++++++++++++++++++++++++++++++++++
branches/release/libs/proto/doc/calculator.qbk | 18 ++--
branches/release/libs/proto/doc/examples.qbk | 15 ++
branches/release/libs/proto/doc/front_end.qbk | 131 ++++++++++++++++++++++++++---
branches/release/libs/proto/doc/glossary.qbk | 14 ++-
branches/release/libs/proto/doc/intermediate_form.qbk | 26 ++--
branches/release/libs/proto/doc/preface.qbk | 6
branches/release/libs/proto/doc/proto.qbk | 4
branches/release/libs/proto/doc/rationale.qbk | 4
branches/release/libs/proto/doc/reference/matches.xml | 19 ++--
branches/release/libs/proto/doc/reference/repeat.xml | 10 +-
branches/release/libs/proto/doc/resources.qbk | 2
branches/release/libs/proto/example/Jamfile.v2 | 5 +
branches/release/libs/proto/example/calc2.cpp | 2
branches/release/libs/proto/example/calc3.cpp | 2
branches/release/libs/proto/example/virtual_member.cpp | 2
17 files changed, 368 insertions(+), 78 deletions(-)
Modified: branches/release/boost/proto/repeat.hpp
==============================================================================
--- branches/release/boost/proto/repeat.hpp (original)
+++ branches/release/boost/proto/repeat.hpp 2011-12-18 19:32:18 EST (Sun, 18 Dec 2011)
@@ -76,7 +76,7 @@
/// \brief Repeatedly invoke the specified macro.
///
/// BOOST_PROTO_REPEAT_FROM_TO_EX() is used generate the kind of repetitive code that is typical
-/// of DSELs built with Proto. BOOST_PROTO_REPEAT_FROM_TO_EX(FROM, TO, MACRO, typename_A, A, A_a, a) is equivalent to:
+/// of EDSLs built with Proto. BOOST_PROTO_REPEAT_FROM_TO_EX(FROM, TO, MACRO, typename_A, A, A_a, a) is equivalent to:
///
/// \code
/// MACRO(FROM, typename_A, A, A_a, a)
@@ -90,7 +90,7 @@
/// \brief Repeatedly invoke the specified macro.
///
/// BOOST_PROTO_REPEAT_FROM_TO() is used generate the kind of repetitive code that is typical
-/// of DSELs built with Proto. BOOST_PROTO_REPEAT_FROM_TO(FROM, TO, MACRO) is equivalent to:
+/// of EDSLs built with Proto. BOOST_PROTO_REPEAT_FROM_TO(FROM, TO, MACRO) is equivalent to:
///
/// \code
/// MACRO(FROM, BOOST_PROTO_typename_A, BOOST_PROTO_A_const_ref, BOOST_PROTO_A_const_ref_a, BOOST_PROTO_ref_a)
@@ -172,7 +172,7 @@
/// \brief Repeatedly invoke the specified macro.
///
/// BOOST_PROTO_REPEAT_EX() is used generate the kind of repetitive code that is typical
-/// of DSELs built with Proto. BOOST_PROTO_REPEAT_EX(MACRO, typename_A, A, A_a, a) is equivalent to:
+/// of EDSLs built with Proto. BOOST_PROTO_REPEAT_EX(MACRO, typename_A, A, A_a, a) is equivalent to:
///
/// \code
/// MACRO(1, typename_A, A, A_a, a)
@@ -186,7 +186,7 @@
/// \brief Repeatedly invoke the specified macro.
///
/// BOOST_PROTO_REPEAT() is used generate the kind of repetitive code that is typical
-/// of DSELs built with Proto. BOOST_PROTO_REPEAT(MACRO) is equivalent to:
+/// of EDSLs built with Proto. BOOST_PROTO_REPEAT(MACRO) is equivalent to:
///
/// \code
/// MACRO(1, BOOST_PROTO_typename_A, BOOST_PROTO_A_const_ref, BOOST_PROTO_A_const_ref_a, BOOST_PROTO_ref_a)
@@ -200,7 +200,7 @@
/// \brief Repeatedly invoke the specified macro.
///
/// BOOST_PROTO_LOCAL_ITERATE() is used generate the kind of repetitive code that is typical
-/// of DSELs built with Proto. This macro causes the user-defined macro BOOST_PROTO_LOCAL_MACRO to
+/// of EDSLs built with Proto. This macro causes the user-defined macro BOOST_PROTO_LOCAL_MACRO to
/// be expanded with values in the range specified by BOOST_PROTO_LOCAL_LIMITS.
///
/// Usage:
Modified: branches/release/libs/proto/doc/back_end.qbk
==============================================================================
--- branches/release/libs/proto/doc/back_end.qbk (original)
+++ branches/release/libs/proto/doc/back_end.qbk 2011-12-18 19:32:18 EST (Sun, 18 Dec 2011)
@@ -10,7 +10,7 @@
Making Expression Templates Do Useful Work]
[/================================================================================]
-Now that you've written the front end for your DSEL compiler, and you've learned a bit about the intermediate form it produces, it's time to think about what to /do/ with the intermediate form. This is where you put your domain-specific algorithms and optimizations. Proto gives you two ways to evaluate and manipulate expression templates: contexts and transforms.
+Now that you've written the front end for your EDSL compiler, and you've learned a bit about the intermediate form it produces, it's time to think about what to /do/ with the intermediate form. This is where you put your domain-specific algorithms and optimizations. Proto gives you two ways to evaluate and manipulate expression templates: contexts and transforms.
* A /context/ is like a function object that you pass along with an expression to
the _eval_ function. It associates behaviors with node types. _eval_ walks the
@@ -696,7 +696,7 @@
[note *Transforms are a Domain-Specific Language*
-`LeftmostLeaf( proto::_child0 )` /looks/ like an invocation of the `LeftmostLeaf` function object, but it's not, but then it actually is! Why this confusing subterfuge? Function types give us a natural and concise syntax for composing more complicated transforms from simpler ones. The fact that the syntax is suggestive of a function invocation is on purpose. It is a domain-specific embedded language for defining expression transformations. If the subterfuge worked, it may have fooled you into thinking the transform is doing exactly what it actually does! And that's the point.]
+`LeftmostLeaf( proto::_child0 )` /looks/ like an invocation of the `LeftmostLeaf` function object, but it's not, but then it actually is! Why this confusing subterfuge? Function types give us a natural and concise syntax for composing more complicated transforms from simpler ones. The fact that the syntax is suggestive of a function invocation is on purpose. It is a embedded domain-specific language for defining expression transformations. If the subterfuge worked, it may have fooled you into thinking the transform is doing exactly what it actually does! And that's the point.]
The type `LeftmostLeaf( proto::_child0 )` is an example of a /callable transform/. It is a function type that represents a function object to call and its arguments. The types `proto::_child0` and `proto::_value` are /primitive transforms/. They are plain structs, not unlike function objects, from which callable transforms can be composed. There is one other type of transform, /object transforms/, that we'll encounter next.
@@ -745,7 +745,7 @@
[section Example: Calculator Arity]
[/================================]
-Now that we have the basics of Proto transforms down, let's consider a slightly more realistic example. We can use transforms to improve the type-safety of the [link boost_proto.users_guide.getting_started.hello_calculator calculator DSEL]. If you recall, it lets you write infix arithmetic expressions involving argument placeholders like `_1` and `_2` and pass them to STL algorithms as function objects, as follows:
+Now that we have the basics of Proto transforms down, let's consider a slightly more realistic example. We can use transforms to improve the type-safety of the [link boost_proto.users_guide.getting_started.hello_calculator calculator EDSL]. If you recall, it lets you write infix arithmetic expressions involving argument placeholders like `_1` and `_2` and pass them to STL algorithms as function objects, as follows:
double a1[4] = { 56, 84, 37, 69 };
double a2[4] = { 65, 120, 60, 70 };
@@ -777,7 +777,7 @@
The expression `_1 * _1` defines a unary calculator expression; it takes one argument and squares it. If we pass more than one argument, the extra arguments will be silently ignored, which might be surprising to users. The next expression, `_2 * _2` defines a binary calculator expression; it takes two arguments, ignores the first and squares the second. If we only pass one argument, the code silently fills in `0.0` for the second argument, which is also probably not what users expect. What can be done?
-We can say that the /arity/ of a calculator expression is the number of arguments it expects, and it is equal to the largest placeholder in the expression. So, the arity of `_1 * _1` is one, and the arity of `_2 * _2` is two. We can increase the type-safety of our calculator DSEL by making sure the arity of an expression equals the actual number of arguments supplied. Computing the arity of an expression is simple with the help of Proto transforms.
+We can say that the /arity/ of a calculator expression is the number of arguments it expects, and it is equal to the largest placeholder in the expression. So, the arity of `_1 * _1` is one, and the arity of `_2 * _2` is two. We can increase the type-safety of our calculator EDSL by making sure the arity of an expression equals the actual number of arguments supplied. Computing the arity of an expression is simple with the help of Proto transforms.
It's straightforward to describe in words how the arity of an expression should
be calculated. Consider that calculator expressions can be made of `_1`, `_2`, literals, unary expressions and binary expressions. The following table shows the arities for each of these 5 constituents.
@@ -1158,6 +1158,174 @@
[endsect]
+[/=============================================================]
+[section:external_transforms Separating Grammars And Transforms]
+[/=============================================================]
+
+[note This is an advanced topic that is only necessary for people defining large EDSLs. Feel free to skip this if you're just getting started with Proto.]
+
+So far, we've seen examples of grammars with embedded transforms. In practice, grammars can get pretty large, and you may want to use them to drive several different computations. For instance, you may have a grammar for a linear algebra domain, and you may want to use it to compute the shape of the result (vector or matrix?) and also to compute the result optimally. You don't want to have to copy and paste the whole shebang just to tweak one of the embedded transforms. What you want instead is to define the grammar once, and specify the transforms later when you're ready to evaluate an expression. For that, you use /external transforms/.
+
+Let's begin this exercise by revisiting our old friend the calculator EDSL. Here is a bare-bones front end that defines a domain, a grammar, an expression wrapper, and some placeholder terminals.
+
+ #include <boost/assert.hpp>
+ #include <boost/mpl/int.hpp>
+ #include <boost/fusion/container/vector.hpp>
+ #include <boost/fusion/container/generation/make_vector.hpp>
+ #include <boost/proto/proto.hpp>
+ namespace mpl = boost::mpl;
+ namespace proto = boost::proto;
+ namespace fusion = boost::fusion;
+
+ // The argument placeholder type
+ template<typename I> struct placeholder : I {};
+
+ // The grammar for valid calculator expressions
+ struct calc_grammar
+ : proto::or_<
+ proto::terminal<placeholder<proto::_> >
+ , proto::terminal<int>
+ , proto::plus<calc_grammar, calc_grammar>
+ , proto::minus<calc_grammar, calc_grammar>
+ , proto::multiplies<calc_grammar, calc_grammar>
+ , proto::divides<calc_grammar, calc_grammar>
+ >
+ {};
+
+ template<typename E> struct calc_expr;
+ struct calc_domain : proto::domain<proto::generator<calc_expr> > {};
+
+ template<typename E>
+ struct calc_expr
+ : proto::extends<E, calc_expr<E>, calc_domain>
+ {
+ calc_expr(E const &e = E()) : calc_expr::proto_extends(e) {}
+ };
+
+ calc_expr<proto::terminal<placeholder<mpl::int_<0> > >::type> _1;
+ calc_expr<proto::terminal<placeholder<mpl::int_<1> > >::type> _2;
+
+ int main()
+ {
+ // Build a calculator expression, and do nothing with it.
+ (_1 + _2);
+ }
+
+Now, let's embed transforms into `calc_grammar` so that we can use it to evaluate calculator expressions:
+
+ // The calculator grammar with embedded transforms for evaluating expression.
+ struct calc_grammar
+ : proto::or_<
+ proto::when<
+ proto::terminal<placeholder<proto::_> >
+ , proto::functional::at(proto::_state, proto::_value)
+ >
+ , proto::when<
+ proto::terminal<int>
+ , proto::_value
+ >
+ , proto::when<
+ proto::plus<calc_grammar, calc_grammar>
+ , proto::_default<calc_grammar>
+ >
+ , proto::when<
+ proto::minus<calc_grammar, calc_grammar>
+ , proto::_default<calc_grammar>
+ >
+ , proto::when<
+ proto::multiplies<calc_grammar, calc_grammar>
+ , proto::_default<calc_grammar>
+ >
+ , proto::when<
+ proto::divides<calc_grammar, calc_grammar>
+ , proto::_default<calc_grammar>
+ >
+ >
+ {};
+
+With this definition of `calc_grammar` we can evaluate expressions by passing along a Fusion vector containing the values to use for the `_1` and `_2` placeholders:
+
+ int result = calc_grammar()(_1 + _2, fusion::make_vector(3, 4));
+ BOOST_ASSERT(result == 7);
+
+Now, imagine we want an alternative evaluation strategy that checks for division by zero and throws an exception. Just how rediculous would it be to copy the entire `calc_grammar` just to change the one line that transforms division expressions?! There are a few ways to solve this problem. One would be to make `calc_grammar` a template parameterized on the division transform. Instead, let's use an external transform.
+
+First, we give the division rule in our grammar a "name"; that is, we make it a struct. We'll use this type later to dispatch to the right transforms.
+
+ struct calc_grammar;
+ struct divides_rule : proto::divides<calc_grammar, calc_grammar> {};
+
+Next, we change `calc_grammar` to make the handling of division expressions external.
+
+ // The calculator grammar with an external transform for evaluating
+ // division expressions.
+ struct calc_grammar
+ : proto::or_<
+ /* ... as before ... */
+ , proto::when<
+ divides_rule
+ , proto::external_transform
+ >
+ >
+ {};
+
+The use of `proto::external_transform` above makes the handling of division expressions externally parameterizeable.
+
+Next, we use `proto::external_transforms<>` (note the trailing 's') to capture our evaluation strategy in a bundle that we can pass along to the transform in the data parameter. Read on for the explanation.
+
+ // Evaluate division nodes as before
+ struct non_checked_division
+ : proto::external_transforms<
+ proto::when< divides_rule, proto::_default<calc_grammar> >
+ >
+ {};
+
+ /* ... */
+
+ non_checked_division non_checked;
+ int result2 = calc_grammar()(_1 / _2, fusion::make_vector(6, 2), non_checked);
+
+The struct `non_cecked_division` associates the transform `proto::_default<calc_grammar>` with the `divides_rule` grammar rule. An instance of that struct is passed along as the third parameter when invoking `calc_grammar`.
+
+Now, let's implement checked division. The rest should be unsurprising.
+
+ struct division_by_zero : std::exception {};
+
+ struct do_checked_divide : proto::callable
+ {
+ typedef int result_type;
+ int operator()(int left, int right) const
+ {
+ if (right == 0) throw division_by_zero();
+ return left / right;
+ }
+ };
+
+ struct checked_division
+ : proto::external_transforms<
+ proto::when<
+ divides_rule
+ , do_checked_divide(calc_grammar(proto::_left), calc_grammar(proto::_right))
+ >
+ >
+ {};
+
+ /* ... */
+
+ try
+ {
+ checked_division checked;
+ int result3 = calc_grammar_extern()(_1 / _2, fusion::make_vector(6, 0), checked);
+ }
+ catch(division_by_zero)
+ {
+ std::cout << "caught division by zero!\n";
+ }
+
+The above code demonstrates how a single grammar can be used with different transforms specified externally. This makes it possibly to reuse a grammar to drive several different computations.
+
+[endsect]
+
[/====================================================]
[section:canned_transforms Proto's Built-In Transforms]
[/====================================================]
Modified: branches/release/libs/proto/doc/calculator.qbk
==============================================================================
--- branches/release/libs/proto/doc/calculator.qbk (original)
+++ branches/release/libs/proto/doc/calculator.qbk 2011-12-18 19:32:18 EST (Sun, 18 Dec 2011)
@@ -10,7 +10,7 @@
[/=======================]
"Hello, world" is nice, but it doesn't get you very far. Let's use Proto to build a
-DSEL (domain-specific embedded language) for a lazily-evaluated calculator. We'll
+EDSL (embedded domain-specific language) for a lazily-evaluated calculator. We'll
see how to define the terminals in your mini-language, how to compose them into
larger expressions, and how to define an evaluation context so that your
expressions can do useful work. When we're done, we'll have a mini-language that
@@ -116,7 +116,7 @@
[heading Customizing Expression Trees]
[/===================================]
-Our calculator DSEL is already pretty useful, and for many DSEL scenarios, no more
+Our calculator EDSL is already pretty useful, and for many EDSL scenarios, no more
would be needed. But let's keep going. Imagine how much nicer it would be if all
calculator expressions overloaded `operator()` so that they could be used as
function objects. We can do that by creating a calculator /domain/ and telling
@@ -205,10 +205,10 @@
your domain. You can detect invalid expressions with Proto by defining the
/grammar/ of your domain-specific language.
-For simplicity, assume that our calculator DSEL should only allow addition,
+For simplicity, assume that our calculator EDSL should only allow addition,
subtraction, multiplication and division. Any expression involving any other
operator is invalid. Using Proto, we can state this requirement by defining the
-grammar of the calculator DSEL. It looks as follows:
+grammar of the calculator EDSL. It looks as follows:
// Define the grammar of calculator expressions
struct calculator_grammar
@@ -225,7 +225,7 @@
[note This grammar is actually a little looser than we would like. Only placeholders and literals that are convertible to doubles are valid terminals. Later on we'll see how to express things like that in Proto grammars.]
-Once you have defined the grammar of your DSEL, you can use the _matches_ metafunction to check whether a given expression type conforms to the grammar. For instance, we might add the following to our `calculator::operator()` overload:
+Once you have defined the grammar of your EDSL, you can use the _matches_ metafunction to check whether a given expression type conforms to the grammar. For instance, we might add the following to our `calculator::operator()` overload:
template<typename Expr>
struct calculator
@@ -242,10 +242,10 @@
};
The addition of the `BOOST_MPL_ASSERT()` line enforces at compile time that we only
-evaluate expressions that conform to the calculator DSEL's grammar. With Proto
+evaluate expressions that conform to the calculator EDSL's grammar. With Proto
grammars, `proto::matches<>` and `BOOST_MPL_ASSERT()` it is very easy to give the
-users of your DSEL short and readable compile-time errors when they accidentally
-misuse your DSEL.
+users of your EDSL short and readable compile-time errors when they accidentally
+misuse your EDSL.
[note `BOOST_MPL_ASSERT()` is part of the Boost Metaprogramming Library. To use it,
just `#include <boost/mpl/assert.hpp>`.]
@@ -258,7 +258,7 @@
an invalid expression and issue a compile-time error. But what if you want to
prevent users from creating invalid expressions in the first place? By using
grammars and domains together, you can disable any of Proto's operator overloads
-that would create an invalid expression. It is as simple as specifying the DSEL's
+that would create an invalid expression. It is as simple as specifying the EDSL's
grammar when you define the domain, as shown below:
// Define a calculator domain. Expression within
Modified: branches/release/libs/proto/doc/examples.qbk
==============================================================================
--- branches/release/libs/proto/doc/examples.qbk (original)
+++ branches/release/libs/proto/doc/examples.qbk 2011-12-18 19:32:18 EST (Sun, 18 Dec 2011)
@@ -18,6 +18,7 @@
[import ../example/map_assign.cpp]
[import ../example/futures.cpp]
[import ../example/mini_lambda.cpp]
+[import ../example/external_transforms.cpp]
[/===============]
[section Examples]
@@ -40,7 +41,7 @@
[section:calc1 Calc1: Defining an Evaluation Context]
[/==================================================]
-A simple example that builds a miniature domain-specific embedded language for lazy arithmetic expressions, with TR1 bind-style argument placeholders.
+A simple example that builds a miniature embedded domain-specific language for lazy arithmetic expressions, with TR1 bind-style argument placeholders.
[Calc1]
@@ -152,10 +153,20 @@
[section:lambda Lambda: A Simple Lambda Library with Proto]
[/========================================================]
-This is an advanced example that shows how to implement a simple lambda DSEL with Proto, like the Boost.Lambda_library. It uses contexts, transforms and expression extension.
+This is an advanced example that shows how to implement a simple lambda EDSL with Proto, like the Boost.Lambda_library. It uses contexts, transforms and expression extension.
[Lambda]
[endsect]
+[/===============================================================================]
+[section:checked_calc Checked Calculator: A Simple Example of External Transforms]
+[/===============================================================================]
+
+This is an advanced example that shows how to externally parameterize a grammar's transforms. It defines a calculator EDSL with a grammar that can perform either checked or unchecked arithmetic.
+
+[CheckedCalc]
+
+[endsect]
+
[endsect]
Modified: branches/release/libs/proto/doc/front_end.qbk
==============================================================================
--- branches/release/libs/proto/doc/front_end.qbk (original)
+++ branches/release/libs/proto/doc/front_end.qbk 2011-12-18 19:32:18 EST (Sun, 18 Dec 2011)
@@ -7,16 +7,16 @@
[/================================================================================]
[section:front_end Fronts Ends:
- Defining Terminals and Non-Terminals of Your DSEL]
+ Defining Terminals and Non-Terminals of Your EDSL]
[/================================================================================]
-Here is the fun part: designing your own mini-programming language. In this section we'll talk about the nuts and bolts of designing a DSEL interface using Proto. We'll cover the definition of terminals and lazy functions that the users of your DSEL will get to program with. We'll also talk about Proto's expression template-building operator overloads, and about ways to add additional members to expressions within your domain.
+Here is the fun part: designing your own mini-programming language. In this section we'll talk about the nuts and bolts of designing a EDSL interface using Proto. We'll cover the definition of terminals and lazy functions that the users of your EDSL will get to program with. We'll also talk about Proto's expression template-building operator overloads, and about ways to add additional members to expressions within your domain.
[/=======================]
[section Making Terminals]
[/=======================]
-As we saw with the Calculator example from the Introduction, the simplest way to get a DSEL up and running is simply to define some terminals, as follows.
+As we saw with the Calculator example from the Introduction, the simplest way to get a EDSL up and running is simply to define some terminals, as follows.
// Define a literal integer Proto expression.
proto::terminal<int>::type i = {0};
@@ -107,13 +107,13 @@
[section Making Lazy Functions]
[/============================]
-If we limited ourselves to nothing but terminals and operator overloads, our domain-specific embedded languages wouldn't be very expressive. Imagine that we wanted to extend our calculator DSEL with a full suite of math functions like `sin()` and `pow()` that we could invoke lazily as follows.
+If we limited ourselves to nothing but terminals and operator overloads, our embedded domain-specific languages wouldn't be very expressive. Imagine that we wanted to extend our calculator EDSL with a full suite of math functions like `sin()` and `pow()` that we could invoke lazily as follows.
// A calculator expression that takes one argument
// and takes the sine of it.
sin(_1);
-We would like the above to create an expression template representing a function invocation. When that expression is evaluated, it should cause the function to be invoked. (At least, that's the meaning of function invocation we'd like the calculator DSEL to have.) You can define `sin` quite simply as follows.
+We would like the above to create an expression template representing a function invocation. When that expression is evaluated, it should cause the function to be invoked. (At least, that's the meaning of function invocation we'd like the calculator EDSL to have.) You can define `sin` quite simply as follows.
// "sin" is a Proto terminal containing a function pointer
proto::terminal< double(*)(double) >::type const sin = {&std::sin};
@@ -140,7 +140,7 @@
[heading Making Lazy Functions, Continued]
[/=======================================]
-Now, what if we wanted to add a `pow()` function to our calculator DSEL that users could invoke as follows?
+Now, what if we wanted to add a `pow()` function to our calculator EDSL that users could invoke as follows?
// A calculator expression that takes one argument
// and raises it to the 2nd power
@@ -163,7 +163,7 @@
Now, let's try to define a function template that returns an expression template. We'll use the _function_ metafunction to calculate the type of a Proto expression that represents a function call. It is analogous to _terminal_. (We'll see a couple of different ways to solve this problem, and each will demonstrate another utility for defining Proto front-ends.)
- // Define a lazy pow() function for the calculator DSEL.
+ // Define a lazy pow() function for the calculator EDSL.
// Can be used as: pow< 2 >(_1)
template<int Exp, typename Arg>
typename proto::function<
@@ -219,7 +219,7 @@
What we want is a way to make `Arg` into a Proto terminal if it is not a Proto expression already, and leave it alone if it is. For that, we can use _as_child_. The following implementation of the `pow()` function handles all argument types, expression templates or otherwise.
- // Define a lazy pow() function for the calculator DSEL. Use
+ // Define a lazy pow() function for the calculator EDSL. Use
// proto::as_child() to Protofy the argument, but only if it
// is not a Proto expression type to begin with!
template<int Exp, typename Arg>
@@ -248,7 +248,7 @@
The versions of the `pow()` function we've seen above are rather verbose. In the return type calculation, you have to be very explicit about wrapping non-Proto types. Worse, you have to restate the return type calculation in the body of `pow()` itself. Proto provides a helper for building expression templates directly that handles these mundane details for you. It's called _make_expr_. We can redefine `pow()` with it as below.
- // Define a lazy pow() function for the calculator DSEL.
+ // Define a lazy pow() function for the calculator EDSL.
// Can be used as: pow< 2 >(_1)
template<int Exp, typename Arg>
typename proto::result_of::make_expr<
@@ -286,7 +286,7 @@
double data[] = {1., 2., 3., 4.};
- // Use the calculator DSEL to square each element ... HOW?
+ // Use the calculator EDSL to square each element ... HOW?
std::transform( data, data + 4, data, _1 * _1 );
The difficulty, if you recall, was that by default Proto expressions don't have interesting behaviors of their own. They're just trees. In particular, the expression `_1 * _1` won't have an `operator()` that takes a double and returns a double like `std::transform()` expects -- unless we give it one. To make this work, we needed to define an expression wrapper type that defined the `operator()` member function, and we needed to associate the wrapper with the calculator /domain/.
@@ -536,7 +536,7 @@
double data[] = {1., 2., 3., 4.};
- // Use the calculator DSEL to square each element ... WORKS! :-)
+ // Use the calculator EDSL to square each element ... WORKS! :-)
std::transform( data, data + 4, data, _1 * _1 );
[endsect]
@@ -546,7 +546,7 @@
[/==========================================================]
By default, Proto defines every possible operator overload for Protofied
-expressions. This makes it simple to bang together a DSEL. In some cases, however, the presence of Proto's promiscuous overloads can lead to confusion or worse. When that happens, you'll have to disable some of Proto's overloaded operators. That is done by defining the grammar for your domain and specifying it as the second parameter of the _domain_ template.
+expressions. This makes it simple to bang together a EDSL. In some cases, however, the presence of Proto's promiscuous overloads can lead to confusion or worse. When that happens, you'll have to disable some of Proto's overloaded operators. That is done by defining the grammar for your domain and specifying it as the second parameter of the _domain_ template.
In the [link boost_proto.users_guide.getting_started.hello_calculator Hello Calculator] section, we saw an example of a Proto grammar, which is repeated here:
@@ -574,7 +574,7 @@
The only new addition is `calculator_grammar` as the second template parameter to the _domain_ template. That has the effect of disabling any of Proto's operator overloads that would create an invalid calculator expression.
-Another common use for this feature would be to disable Proto's unary `operator&` overload. It may be surprising for users of your DSEL that they cannot take the address of their expressions! You can very easily disable Proto's unary `operator&` overload for your domain with a very simple grammar, as below:
+Another common use for this feature would be to disable Proto's unary `operator&` overload. It may be surprising for users of your EDSL that they cannot take the address of their expressions! You can very easily disable Proto's unary `operator&` overload for your domain with a very simple grammar, as below:
// For expressions in my_domain, disable Proto's
// unary address-of operator.
@@ -658,9 +658,9 @@
[section:code_repetition Generating Repetitive Code with the Preprocessor]
[/=======================================================================]
-Sometimes as a DSEL designer, to make the lives of your users easy, you have to make your own life hard. Giving your users natural and flexible syntax often involves writing large numbers of repetitive function overloads. It can be enough to give you repetitive stress injury! Before you hurt yourself, check out the macros Proto provides for automating many repetitive code-generation chores.
+Sometimes as a EDSL designer, to make the lives of your users easy, you have to make your own life hard. Giving your users natural and flexible syntax often involves writing large numbers of repetitive function overloads. It can be enough to give you repetitive stress injury! Before you hurt yourself, check out the macros Proto provides for automating many repetitive code-generation chores.
-Imagine that we are writing a lambda DSEL, and we would like to enable syntax for constructing temporary objects of any type using the following syntax:
+Imagine that we are writing a lambda EDSL, and we would like to enable syntax for constructing temporary objects of any type using the following syntax:
// A lambda expression that takes two arguments and
// uses them to construct a temporary std::complex<>
@@ -732,4 +732,105 @@
[endsect]
+[/======================================================]
+[section:subdomains EDSL Interoperatability: Sub-Domains]
+[/======================================================]
+
+The ability to /compose/ different EDSLs is one of their most exciting features. Consider how you build a parser using yacc. You write your grammar rules in yacc's domain-specific language. Then you embed semantic actions written in C within your grammar. Boost's Spirit parser generator gives you the same ability. You write grammar rules using Spirit and embed semantic actions using the Phoenix library. Phoenix and Spirit are both Proto-based domain-specific languages with their own distinct syntax and semantics. But you can freely embed Phoenix expressions within Spirit expressions. This section describes Proto's /sub-domain/ feature that lets you define famalies of interoperable domains.
+
+[/======================]
+[heading Dueling Domains]
+[/======================]
+
+Sub-domains solve a specific problem that only comes up when you try to create an expression from two sub-expressions in different domains: what is the domain of the resulting expression? Consider the following code:
+
+ #include <boost/proto/proto.hpp>
+ namespace proto = boost::proto;
+
+ // Forward-declare two expression wrappers
+ template<typename E> struct spirit_expr;
+ template<typename E> struct phoenix_expr;
+
+ // Define two domains
+ struct spirit_domain : proto::domain<proto::generator<spirit_expr> > {};
+ struct phoenix_domain : proto::domain<proto::generator<phoenix_expr> > {};
+
+ // Implement the two expresison wrappers
+ template<typename E>
+ struct spirit_expr
+ : proto::extends<E, spirit_expr<E>, spirit_domain>
+ {
+ spirit_expr(E const &e = E()) : spirit_expr::proto_extends(e) {}
+ };
+
+ template<typename E>
+ struct phoenix_expr
+ : proto::extends<E, phoenix_expr<E>, phoenix_domain>
+ {
+ phoenix_expr(E const &e = E()) : phoenix_expr::proto_extends(e) {}
+ };
+
+ int main()
+ {
+ proto::literal<int, spirit_domain> sp(0);
+ proto::literal<int, phoenix_domain> phx(0);
+
+ // Whoops! What does it mean to add two expression in different domains?
+ sp + phx; // ERROR
+ }
+
+Above, we define two domains called `spirit_domain` and `phoenix_domain` and declare two int literals in each. Then we try to compose them into a larger expression using Proto's binary plus operator, and it fails. Proto can't figure out whether the resulting expression should be in the Spirit domain or the Phoenix domain, and thus whether it should be an instance of `spirit_expr<>` or `pheonix_expr<>`. We have to tell Proto how to resolve the conflict. We can do that by declaring that Phoenix is a sub-domain of Spirit as in the following definition of `phoenix_domain`:
+
+ // Declare that phoenix_domain is a sub-somain of spirit_domain
+ struct phoenix_domain
+ : proto::domain<proto::generator<phoenix_expr>, proto::_, spirit_domain>
+ {};
+
+The third template parameter to _domain_ is the super-domain. By defining `phoenix_domain` as above, we are saying that Phoenix expressions can be combined with Spirit expressions, and that when that happens, the resulting expression should be a Spirit expression.
+
+[note If you are wondering what the purpose of `proto::_` is in the definition of `phoenix_domain` above, recall that the second template parameter to _domain_ is the domain's grammar. ["`proto::_`] is the default and signifies that the domain places no restrictions on the expressions that are valid within it.]
+
+[/------------------------]
+[heading Domain Resolution]
+[/------------------------]
+
+When there are multiple domains in play within a given expression, Proto uses some rules to figure out which domain "wins". The rules are loosly modeled on the rules for C++ inheritance. `Phoenix_domain` is a sub-domain of `spirit_domain`. You can liken that to a derived/base relationship that gives Phoenix expressions a kind of implicit conversion to Spirit expressions. And since Phoenix expressions can be "converted" to Spirit expressions, they can be freely combined with Spirit expressions and the result is a Spirit expression.
+
+[note Super- and sub-domains are not actually implemented using inheritance. This is only a helpful mental model.]
+
+The analogy with inheritance holds even in the case of three domains when two are sub-domains of the third. Imagine another domain called `foobar_domain` that was also a sub-domain of `spirit_domain`. Expressions in the `foobar_domain` could be combined with expressions in the `phoenix_domain` and the resulting expression would be in the `spirit_domain`. That's because expressions in the two sub-domains both have "conversions" to the super-domain, so the operation is allowed and the super-domain wins.
+
+[/-------------------------]
+[heading The Default Domain]
+[/-------------------------]
+
+When you don't assign a Proto expression to a particular domain, Proto considers it a member of the so-called default domain, `proto::default_domain`. Even non-Proto objects are treated as terminals in the default domain. Consider:
+
+ int main()
+ {
+ proto::literal<int, spirit_domain> sp(0);
+
+ // Add 1 to a spirit expression. Result is a spirit expression.
+ sp + 1;
+ }
+
+In light of the above discussion about sub-domains, you might consider `proto::default_domain` as a sub-domain of every other domain. Expressions in the default domain have a kind of implicit conversion to every other domain type. That's exactly how Proto sees it! What's more, you can define your domain to be a sub-domain of the default domain. In so doing, you give expression in your domain conversions to expressions in /every other domain/. This is like a "free love" domain, because it will freely mix with all other domains.
+
+Let's think again about the Phoenix EDSL. Since it provides generally useful lambda functionionality, it's reasonable to assume that lots of other EDSLs besides Spirit might want the ability to embed Phoenix expressions. In other words, `phoenix_domain` should be a sub-domain of `proto::default_domain`, not `spirit_domain`:
+
+ // Declare that phoenix_domain is a sub-somain of proto::default_domain
+ struct phoenix_domain
+ : proto::domain<proto::generator<phoenix_expr>, proto::_, proto::default_domain>
+ {};
+
+That's much better. Phoenix expressions can now be put anywhere.
+
+[/-------------------------]
+[heading Sub-Domain Summary]
+[/-------------------------]
+
+Use Proto sub-domains to make it possible to mix expressions from multiple domains. And when you want expressions in your domain to freely combine with /all/ expressions, make it a sub-domain of `proto::default_domain`.
+
+[endsect]
+
[endsect]
Modified: branches/release/libs/proto/doc/glossary.qbk
==============================================================================
--- branches/release/libs/proto/doc/glossary.qbk (original)
+++ branches/release/libs/proto/doc/glossary.qbk 2011-12-18 19:32:18 EST (Sun, 18 Dec 2011)
@@ -35,14 +35,14 @@
overloads such that expressions not conforming to the domain's grammar are
never created. Domains are empty structs that inherit from
`proto::domain<>`.]]
- [ [ [anchor dsel] domain-specific embedded language]
- [A domain-specific language implemented as a library. The language in which
- the library is written is called the "host" language, and the language
- implemented by the library is called the "embedded" language.]]
[ [ [anchor dsl] domain-specific language]
[A programming language that targets a particular problem space by providing
programming idioms, abstractions and constructs that match the constructs
within that problem space.]]
+ [ [ [anchor edsl] embedded domain-specific language]
+ [A domain-specific language implemented as a library. The language in which
+ the library is written is called the "host" language, and the language
+ implemented by the library is called the "embedded" language.]]
[ [ [anchor expression] expression]
[In Proto, an /expression/ is a heterogeneous tree where each node is either
an instantiation of `boost::proto::expr<>`, `boost::proto::basic_expr<>` or
@@ -52,7 +52,7 @@
[A C++ technique using templates and operator overloading to cause
expressions to build trees that represent the expression for lazy evaluation
later, rather than evaluating the expression eagerly. Some C++ libraries use
- expression templates to build domain-specific embedded languages.]]
+ expression templates to build embedded domain-specific languages.]]
[ [ [anchor generator] generator]
[In Proto, a /generator/ is a unary polymorphic function object that you
specify when defining a /domain/. After constructing a new expression, Proto
@@ -79,6 +79,10 @@
[A type that defines a kind of polymorphic function object that takes three
arguments: expression, state, and data. Primitive transforms can be used to
compose callable transforms and object transforms.]]
+ [ [ [anchor subdomain] sub-domain]
+ [A sub-domain is a domain that declares another domain as its super-domain.
+ Expressions in sub-domains can be combined with expressions in the
+ super-domain, and the resulting expression is in the super-domain.]]
[ [ [anchor transform] transform]
[Transforms are used to manipulate expression trees. They come in three
flavors: primitive transforms, callable transforms, or object transforms. A
Modified: branches/release/libs/proto/doc/intermediate_form.qbk
==============================================================================
--- branches/release/libs/proto/doc/intermediate_form.qbk (original)
+++ branches/release/libs/proto/doc/intermediate_form.qbk 2011-12-18 19:32:18 EST (Sun, 18 Dec 2011)
@@ -23,7 +23,7 @@
Understanding and Introspecting Expressions]
[/================================================================================]
-By now, you know a bit about how to build a front-end for your DSEL "compiler" -- you can define terminals and functions that generate expression templates. But we haven't said anything about the expression templates themselves. What do they look like? What can you do with them? In this section we'll see.
+By now, you know a bit about how to build a front-end for your EDSL "compiler" -- you can define terminals and functions that generate expression templates. But we haven't said anything about the expression templates themselves. What do they look like? What can you do with them? In this section we'll see.
[/=========================]
[heading The [^expr<>] Type]
@@ -287,7 +287,7 @@
[section Deep-copying Expressions]
[/===============================]
-When you build an expression template with Proto, all the intermediate child nodes are held /by reference/. The avoids needless copies, which is crucial if you want your DSEL to perform well at runtime. Naturally, there is a danger if the temporary objects go out of scope before you try to evaluate your expression template. This is especially a problem in C++0x with the new `decltype` and `auto` keywords. Consider:
+When you build an expression template with Proto, all the intermediate child nodes are held /by reference/. The avoids needless copies, which is crucial if you want your EDSL to perform well at runtime. Naturally, there is a danger if the temporary objects go out of scope before you try to evaluate your expression template. This is especially a problem in C++0x with the new `decltype` and `auto` keywords. Consider:
// OOPS: "ex" is left holding dangling references
auto ex = proto::lit(1) + 2;
@@ -322,7 +322,7 @@
[section Debugging Expressions]
[/============================]
-Proto provides a utility for pretty-printing expression trees that comes in very handy when you're trying to debug your DSEL. It's called _display_expr_, and you pass it the expression to print and optionally, an `std::ostream` to which to send the output. Consider:
+Proto provides a utility for pretty-printing expression trees that comes in very handy when you're trying to debug your EDSL. It's called _display_expr_, and you pass it the expression to print and optionally, an `std::ostream` to which to send the output. Consider:
// Use display_expr() to pretty-print an expression tree
proto::display_expr(
@@ -661,7 +661,7 @@
[section:patterns Finding Patterns in Expressions]
[/===============================================]
-Imagine your DSEL is a miniature I/O facility, with iostream operations that execute lazily. You might want expressions representing input operations to be processed by one function, and output operations to be processed by a different function. How would you do that?
+Imagine your EDSL is a miniature I/O facility, with iostream operations that execute lazily. You might want expressions representing input operations to be processed by one function, and output operations to be processed by a different function. How would you do that?
The answer is to write patterns (a.k.a, /grammars/) that match the structure of input and output expressions. Proto provides utilities for defining the grammars, and the _matches_ template for checking whether a given expression type matches the grammar.
@@ -829,7 +829,7 @@
The inverse problem is a little trickier: what if you wanted to match all character arrays, but not character pointers? As mentioned above, the expression `as_expr("hello")` has the type `proto::terminal< char const[ 6 ] >::type`. If you wanted to match character arrays of arbitrary size, you could use `proto::N`, which is an array-size wildcard. The following grammar would match any string literal: `proto::terminal< char const[ proto::N ] >`.
-Sometimes you need even more wiggle room when matching terminals. For example, maybe you're building a calculator DSEL and you want to allow any terminals that are convertible to `double`. For that, Proto provides the _convertible_to_ template. You can use it as: `proto::terminal< proto::convertible_to< double > >`.
+Sometimes you need even more wiggle room when matching terminals. For example, maybe you're building a calculator EDSL and you want to allow any terminals that are convertible to `double`. For that, Proto provides the _convertible_to_ template. You can use it as: `proto::terminal< proto::convertible_to< double > >`.
There is one more way you can perform a fuzzy match on terminals. Consider the problem of trying to match a `std::complex<>` terminal. You can easily match a `std::complex<float>` or a `std::complex<double>`, but how would you match any instantiation of `std::complex<>`? You can use `proto::_` here to solve this problem. Here is the grammar to match any `std::complex<>` instantiation:
@@ -892,7 +892,7 @@
>
{};
-The above might be the grammar to a more elaborate calculator DSEL. Notice that since there are more than eight sub-grammars, we had to chain the sub-grammars with a nested _or_ -- not very nice.
+The above might be the grammar to a more elaborate calculator EDSL. Notice that since there are more than eight sub-grammars, we had to chain the sub-grammars with a nested _or_ -- not very nice.
The idea behind _switch_ is to dispatch based on an expression's tag type to a sub-grammar that handles expressions of that type. To use _switch_, you define a struct with a nested `case_<>` template, specialized on tag types. The above grammar can be expressed using _switch_ as follows. It is described below.
@@ -1056,24 +1056,24 @@
[endsect]
[/=============================]
-[section Defining DSEL Grammars]
+[section Defining EDSL Grammars]
[/=============================]
-In this section we'll see how to use Proto to define a grammar for your DSEL and use it to validate expression templates, giving short, readable compile-time errors for invalid expressions.
+In this section we'll see how to use Proto to define a grammar for your EDSL and use it to validate expression templates, giving short, readable compile-time errors for invalid expressions.
[tip You might think that this is a backwards way of doing things. ["If Proto let
me select which operators to overload, my users wouldn't be able to create invalid
expressions in the first place, and I wouldn't need a grammar at all!] That may be
true, but there are reasons for preferring to do things this way.
-First, it lets you develop your DSEL rapidly -- all the operators are there for you
+First, it lets you develop your EDSL rapidly -- all the operators are there for you
already! -- and worry about invalid syntax later.
Second, it might be the case that some operators are only allowed in certain
-contexts within your DSEL. This is easy to express with a grammar, and hard to do
+contexts within your EDSL. This is easy to express with a grammar, and hard to do
with straight operator overloading.
-Third, using a DSEL grammar to flag invalid expressions can often yield better
+Third, using a EDSL grammar to flag invalid expressions can often yield better
errors than manually selecting the overloaded operators.
Fourth, the grammar can be used for more than just validation. You can use your
@@ -1084,7 +1084,7 @@
operators are overloaded within your domain. And to do it, you need to define a
grammar!]
-In a previous section, we used Proto to define a DSEL for a lazily evaluated calculator that allowed any combination of placeholders, floating-point literals, addition, subtraction, multiplication, division and grouping. If we were to write the grammar for this DSEL in [@http://en.wikipedia.org/wiki/Extended_Backus_Naur_Form EBNF], it might look like this:
+In a previous section, we used Proto to define a EDSL for a lazily evaluated calculator that allowed any combination of placeholders, floating-point literals, addition, subtraction, multiplication, division and grouping. If we were to write the grammar for this EDSL in [@http://en.wikipedia.org/wiki/Extended_Backus_Naur_Form EBNF], it might look like this:
[pre
group ::= '(' expression ')'
@@ -1094,7 +1094,7 @@
]
This captures the syntax, associativity and precedence rules of a calculator.
-Writing the grammar for our calculator DSEL using Proto is /even simpler/.
+Writing the grammar for our calculator EDSL using Proto is /even simpler/.
Since we are using C++ as the host language, we are bound to the associativity
and precedence rules for the C++ operators. Our grammar can assume them. Also,
in C++ grouping is already handled for us with the use of parenthesis, so we
Modified: branches/release/libs/proto/doc/preface.qbk
==============================================================================
--- branches/release/libs/proto/doc/preface.qbk (original)
+++ branches/release/libs/proto/doc/preface.qbk 2011-12-18 19:32:18 EST (Sun, 18 Dec 2011)
@@ -13,7 +13,7 @@
[heading Description]
-Proto is a framework for building Domain Specific Embedded Languages in C++. It provides tools for constructing, type-checking, transforming and executing ['expression templates][footnote See [@http://www.osl.iu.edu/~tveldhui/papers/Expression-Templates/exprtmpl.html Expression Templates]].
+Proto is a framework for building Embedded Domain-Specific Languages in C++. It provides tools for constructing, type-checking, transforming and executing ['expression templates][footnote See [@http://www.osl.iu.edu/~tveldhui/papers/Expression-Templates/exprtmpl.html Expression Templates]].
More specifically, Proto provides:
* An expression tree data structure.
@@ -25,9 +25,9 @@
[heading Motivation]
-Expression Templates are an advanced technique that C++ library developers use to define embedded mini-languages that target specific problem domains. The technique has been used to create efficient and easy-to-use libraries for linear algebra as well as to define C++ parser generators with a readable syntax. But developing such a library involves writing an inordinate amount of unreadable and unmaintainable template mumbo-jumbo. Boost.Proto eases the development of [link boost_proto.users_guide.glossary.dsel domain-specific embedded languages (DSELs)]. Use Proto to define the primitives of your mini-language and let Proto handle the operator overloading and the construction of the expression parse tree. Immediately evaluate the expression tree by passing it a function object. Or transform the expression tree by defining the grammar of your mini-language, decorated with an assortment of tree transforms provided by Proto or defined by you. Then use the grammar to give your users short and readable syntax err
ors for invalid expressions! No more mumbo-jumbo -- an expression template library developed with Proto is declarative and readable.
+Expression Templates are an advanced technique that C++ library developers use to define embedded mini-languages that target specific problem domains. The technique has been used to create efficient and easy-to-use libraries for linear algebra as well as to define C++ parser generators with a readable syntax. But developing such a library involves writing an inordinate amount of unreadable and unmaintainable template mumbo-jumbo. Boost.Proto eases the development of [link boost_proto.users_guide.glossary.edsl domain-specific embedded languages (EDSLs)]. Use Proto to define the primitives of your mini-language and let Proto handle the operator overloading and the construction of the expression parse tree. Immediately evaluate the expression tree by passing it a function object. Or transform the expression tree by defining the grammar of your mini-language, decorated with an assortment of tree transforms provided by Proto or defined by you. Then use the grammar to give your users short and readable syntax err
ors for invalid expressions! No more mumbo-jumbo -- an expression template library developed with Proto is declarative and readable.
-In short, Proto is a DSEL for defining DSELs.
+In short, Proto is a EDSL for defining EDSLs.
[/====================================]
[heading How to Use This Documentation]
Modified: branches/release/libs/proto/doc/proto.qbk
==============================================================================
--- branches/release/libs/proto/doc/proto.qbk (original)
+++ branches/release/libs/proto/doc/proto.qbk 2011-12-18 19:32:18 EST (Sun, 18 Dec 2011)
@@ -248,7 +248,7 @@
Most compilers have front ends and back ends. The front end parses the text of an input program into some intermediate form like an abstract syntax tree, and the back end takes the intermediate form and generates an executable from it.
-A library built with Proto is essentially a compiler for a domain-specific embedded language (DSEL). It also has a front end, an intermediate form, and a back end. The front end is comprised of the symbols (a.k.a., terminals), members, operators and functions that make up the user-visible aspects of the DSEL. The back end is made of evaluation contexts and transforms that give meaning and behavior to the expression templates generated by the front end. In between is the intermediate form: the expression template itself, which is an abstract syntax tree in a very real sense.
+A library built with Proto is essentially a compiler for a embedded domain-specific language (EDSL). It also has a front end, an intermediate form, and a back end. The front end is comprised of the symbols (a.k.a., terminals), members, operators and functions that make up the user-visible aspects of the EDSL. The back end is made of evaluation contexts and transforms that give meaning and behavior to the expression templates generated by the front end. In between is the intermediate form: the expression template itself, which is an abstract syntax tree in a very real sense.
To build a library with Proto, you will first decide what your interface will be; that is, you'll design a programming language for your domain and build the front end with tools provided by Proto. Then you'll design the back end by writing evaluation contexts and/or transforms that accept expression templates and do interesting things with them.
@@ -256,7 +256,7 @@
[variablelist
[[[link boost_proto.users_guide.front_end Front Ends]]
- [How to define the aspects of your DSEL with which your users will interact directly.]]
+ [How to define the aspects of your EDSL with which your users will interact directly.]]
[[[link boost_proto.users_guide.intermediate_form Intermediate Form]]
[What Proto expression templates look like, how to discover their structure and access their constituents.]]
[[[link boost_proto.users_guide.back_end Back Ends]]
Modified: branches/release/libs/proto/doc/rationale.qbk
==============================================================================
--- branches/release/libs/proto/doc/rationale.qbk (original)
+++ branches/release/libs/proto/doc/rationale.qbk 2011-12-18 19:32:18 EST (Sun, 18 Dec 2011)
@@ -16,8 +16,8 @@
terminal<int>::type const _i = {1};
The reason is so that expression objects like `_i` above can be ['statically
-initialized]. Why is static initialization important? The terminals of many domain-
-specific embedded languages are likely to be global const objects, like `_1` and
+initialized]. Why is static initialization important? The terminals of many embedded
+domain-specific languages are likely to be global const objects, like `_1` and
`_2` from the Boost Lambda Library. Were these object to require run-time
initialization, it might be possible to use these objects before they are
initialized. That would be bad. Statically initialized objects cannot be misused
Modified: branches/release/libs/proto/doc/reference/matches.xml
==============================================================================
--- branches/release/libs/proto/doc/reference/matches.xml (original)
+++ branches/release/libs/proto/doc/reference/matches.xml 2011-12-18 19:32:18 EST (Sun, 18 Dec 2011)
@@ -427,24 +427,24 @@
<struct name="switch_">
<template>
<template-type-parameter name="Cases"/>
- <template-type-parameter name="Transform"/>
+ <template-type-parameter name="Transform"/>
</template>
<inherit><classname>proto::transform</classname><switch_<Cases, Transform> ></inherit>
<purpose>For matching one of a set of alternate grammars, which are looked up based on
the result type of the transform passed in second template parameter.
- If no transform is passed, the default one is <computeroutput>proto::tag_of()</computeroutput>
+ If no transform is passed, the default one is <computeroutput><classname>proto::tag_of</classname><<classname>proto::_</classname>>()</computeroutput>
so the default matching is based on the expression's tag type. When used as a transform,
<computeroutput>proto::switch_<></computeroutput> applies the transform associated
with the sub-grammar that matches the expression.</purpose>
<description>
- <para>
- An expression type <computeroutput>E</computeroutput> matches
+ <para>
+ An expression type <computeroutput>E</computeroutput> matches
<computeroutput>proto::switch_<C,T></computeroutput> if
- <computeroutput>E</computeroutput> matches
+ <computeroutput>E</computeroutput> matches
<computeroutput>C::case_<boost::result_of<T(E)>::type></computeroutput>.
</para>
- <para>
- When applying <computeroutput>proto::switch_<C,T></computeroutput> as a
+ <para>
+ When applying <computeroutput>proto::switch_<C,T></computeroutput> as a
transform with an expression <computeroutput>e</computeroutput> of type
<computeroutput>E</computeroutput>, state <computeroutput>s</computeroutput> of
type <computeroutput>S</computeroutput> and data <computeroutput>d</computeroutput>
@@ -697,9 +697,10 @@
<para>
An expression <computeroutput>E</computeroutput> matches
<computeroutput>
- <classname>proto::switch_</classname><C>
+ <classname>proto::switch_</classname><C, T>
</computeroutput> if
- <computeroutput>E</computeroutput> matches <computeroutput>C::case_<E::proto_tag></computeroutput>.
+ <computeroutput>E</computeroutput> matches <computeroutput>C::case_<boost::result_of<T(E)>::type></computeroutput>.
+ Note: <computeroutput>T</computeroutput> defaults to <computeroutput><classname>proto::tag_of</classname><<classname>proto::_</classname>>()</computeroutput>
</para>
</listitem>
</itemizedlist>
Modified: branches/release/libs/proto/doc/reference/repeat.xml
==============================================================================
--- branches/release/libs/proto/doc/reference/repeat.xml (original)
+++ branches/release/libs/proto/doc/reference/repeat.xml 2011-12-18 19:32:18 EST (Sun, 18 Dec 2011)
@@ -10,7 +10,7 @@
<description>
<para>
<computeroutput>BOOST_PROTO_REPEAT()</computeroutput> is used to generate the kind of repetitive
- code that is typical of DSELs built with Proto.
+ code that is typical of EDSLs built with Proto.
<computeroutput>BOOST_PROTO_REPEAT(<replaceable>MACRO</replaceable>)</computeroutput>
is equivalent to:
</para>
@@ -37,7 +37,7 @@
<description>
<para>
<computeroutput>BOOST_PROTO_REPEAT_FROM_TO()</computeroutput> is used to generate the kind of repetitive
- code that is typical of DSELs built with Proto.
+ code that is typical of EDSLs built with Proto.
<computeroutput>BOOST_PROTO_REPEAT_FROM_TO(<replaceable>FROM</replaceable>, <replaceable>TO</replaceable>, <replaceable>MACRO</replaceable>)</computeroutput>
is equivalent to:
</para>
@@ -126,7 +126,7 @@
<description>
<para>
<computeroutput>BOOST_PROTO_REPEAT_EX()</computeroutput> is used to generate the kind of repetitive
- code that is typical of DSELs built with Proto.
+ code that is typical of EDSLs built with Proto.
<computeroutput>BOOST_PROTO_REPEAT_EX(<replaceable>MACRO</replaceable>, <replaceable>typename_A</replaceable>, <replaceable>A</replaceable>, <replaceable>A_a</replaceable>, <replaceable>a</replaceable>)</computeroutput>
is equivalent to:
</para>
@@ -157,7 +157,7 @@
<description>
<para>
<computeroutput>BOOST_PROTO_REPEAT_FROM_TO_EX()</computeroutput> is used to generate the kind of repetitive
- code that is typical of DSELs built with Proto.
+ code that is typical of EDSLs built with Proto.
<computeroutput>BOOST_PROTO_REPEAT_FROM_TO_EX(<replaceable>FROM</replaceable>, <replaceable>TO</replaceable>, <replaceable>MACRO</replaceable>, <replaceable>typename_A</replaceable>, <replaceable>A</replaceable>, <replaceable>A_a</replaceable>, <replaceable>a</replaceable>)</computeroutput>
is equivalent to:
</para>
@@ -181,7 +181,7 @@
<description>
<para>
<computeroutput>BOOST_PROTO_LOCAL_ITERATE()</computeroutput> is used generate the kind of repetitive code that is typical
- of DSELs built with Proto. This macro causes the user-defined macro <computeroutput>BOOST_PROTO_LOCAL_MACRO()</computeroutput> to
+ of EDSLs built with Proto. This macro causes the user-defined macro <computeroutput>BOOST_PROTO_LOCAL_MACRO()</computeroutput> to
be expanded with values in the range specified by <computeroutput>BOOST_PROTO_LOCAL_LIMITS</computeroutput>.
</para>
<para>
Modified: branches/release/libs/proto/doc/resources.qbk
==============================================================================
--- branches/release/libs/proto/doc/resources.qbk (original)
+++ branches/release/libs/proto/doc/resources.qbk 2011-12-18 19:32:18 EST (Sun, 18 Dec 2011)
@@ -14,7 +14,7 @@
of matching a regular expression. Since then, Proto has found application in the
redesigned and improved Spirit-2 and the related Karma library. As a result of
these efforts, Proto evolved into a generic and abstract grammar and tree
-transformation framework applicable in a wide variety of DSEL scenarios.
+transformation framework applicable in a wide variety of EDSL scenarios.
The grammar and tree transformation framework is modeled on Spirit's grammar and
semantic action framework. The expression tree data structure is similar to Fusion
Modified: branches/release/libs/proto/example/Jamfile.v2
==============================================================================
--- branches/release/libs/proto/example/Jamfile.v2 (original)
+++ branches/release/libs/proto/example/Jamfile.v2 2011-12-18 19:32:18 EST (Sun, 18 Dec 2011)
@@ -72,3 +72,8 @@
:
virtual_member.cpp
;
+
+exe external_transforms
+ :
+ external_transforms.cpp
+ ;
Modified: branches/release/libs/proto/example/calc2.cpp
==============================================================================
--- branches/release/libs/proto/example/calc2.cpp (original)
+++ branches/release/libs/proto/example/calc2.cpp 2011-12-18 19:32:18 EST (Sun, 18 Dec 2011)
@@ -60,7 +60,7 @@
: calculator_expression::proto_extends(expr)
{}
- BOOST_PROTO_EXTENDS_USING_ASSIGN(calculator_expression)
+ BOOST_PROTO_EXTENDS_USING_ASSIGN(calculator_expression<Expr>)
// Override operator () to evaluate the expression
double operator ()() const
Modified: branches/release/libs/proto/example/calc3.cpp
==============================================================================
--- branches/release/libs/proto/example/calc3.cpp (original)
+++ branches/release/libs/proto/example/calc3.cpp 2011-12-18 19:32:18 EST (Sun, 18 Dec 2011)
@@ -101,7 +101,7 @@
: base_type(expr)
{}
- BOOST_PROTO_EXTENDS_USING_ASSIGN(calculator_expression)
+ BOOST_PROTO_EXTENDS_USING_ASSIGN(calculator_expression<Expr>)
// Override operator () to evaluate the expression
double operator ()() const
Modified: branches/release/libs/proto/example/virtual_member.cpp
==============================================================================
--- branches/release/libs/proto/example/virtual_member.cpp (original)
+++ branches/release/libs/proto/example/virtual_member.cpp 2011-12-18 19:32:18 EST (Sun, 18 Dec 2011)
@@ -75,7 +75,7 @@
static const value_type value = N::value;
};
- // Some keyword types for our lambda DSEL
+ // Some keyword types for our lambda EDSL
namespace keyword
{
struct if_ {};
Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk