|
|
Boost-Commit : |
Subject: [Boost-commit] svn:boost r76028 - in trunk: boost/proto libs/proto/doc libs/proto/doc/reference libs/proto/example
From: eric_at_[hidden]
Date: 2011-12-17 14:44:05
Author: eric_niebler
Date: 2011-12-17 14:44:03 EST (Sat, 17 Dec 2011)
New Revision: 76028
URL: http://svn.boost.org/trac/boost/changeset/76028
Log:
s/DSEL/EDSL/
Text files modified:
trunk/boost/proto/repeat.hpp | 10 +++++-----
trunk/libs/proto/doc/back_end.qbk | 8 ++++----
trunk/libs/proto/doc/calculator.qbk | 18 +++++++++---------
trunk/libs/proto/doc/examples.qbk | 4 ++--
trunk/libs/proto/doc/front_end.qbk | 30 +++++++++++++++---------------
trunk/libs/proto/doc/glossary.qbk | 10 +++++-----
trunk/libs/proto/doc/intermediate_form.qbk | 26 +++++++++++++-------------
trunk/libs/proto/doc/preface.qbk | 6 +++---
trunk/libs/proto/doc/proto.qbk | 4 ++--
trunk/libs/proto/doc/rationale.qbk | 4 ++--
trunk/libs/proto/doc/reference/repeat.xml | 10 +++++-----
trunk/libs/proto/doc/resources.qbk | 2 +-
trunk/libs/proto/example/calc2.cpp | 2 +-
trunk/libs/proto/example/calc3.cpp | 2 +-
trunk/libs/proto/example/virtual_member.cpp | 2 +-
15 files changed, 69 insertions(+), 69 deletions(-)
Modified: trunk/boost/proto/repeat.hpp
==============================================================================
--- trunk/boost/proto/repeat.hpp (original)
+++ trunk/boost/proto/repeat.hpp 2011-12-17 14:44:03 EST (Sat, 17 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: trunk/libs/proto/doc/back_end.qbk
==============================================================================
--- trunk/libs/proto/doc/back_end.qbk (original)
+++ trunk/libs/proto/doc/back_end.qbk 2011-12-17 14:44:03 EST (Sat, 17 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.
Modified: trunk/libs/proto/doc/calculator.qbk
==============================================================================
--- trunk/libs/proto/doc/calculator.qbk (original)
+++ trunk/libs/proto/doc/calculator.qbk 2011-12-17 14:44:03 EST (Sat, 17 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: trunk/libs/proto/doc/examples.qbk
==============================================================================
--- trunk/libs/proto/doc/examples.qbk (original)
+++ trunk/libs/proto/doc/examples.qbk 2011-12-17 14:44:03 EST (Sat, 17 Dec 2011)
@@ -40,7 +40,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,7 +152,7 @@
[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]
Modified: trunk/libs/proto/doc/front_end.qbk
==============================================================================
--- trunk/libs/proto/doc/front_end.qbk (original)
+++ trunk/libs/proto/doc/front_end.qbk 2011-12-17 14:44:03 EST (Sat, 17 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<>
Modified: trunk/libs/proto/doc/glossary.qbk
==============================================================================
--- trunk/libs/proto/doc/glossary.qbk (original)
+++ trunk/libs/proto/doc/glossary.qbk 2011-12-17 14:44:03 EST (Sat, 17 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
Modified: trunk/libs/proto/doc/intermediate_form.qbk
==============================================================================
--- trunk/libs/proto/doc/intermediate_form.qbk (original)
+++ trunk/libs/proto/doc/intermediate_form.qbk 2011-12-17 14:44:03 EST (Sat, 17 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: trunk/libs/proto/doc/preface.qbk
==============================================================================
--- trunk/libs/proto/doc/preface.qbk (original)
+++ trunk/libs/proto/doc/preface.qbk 2011-12-17 14:44:03 EST (Sat, 17 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: trunk/libs/proto/doc/proto.qbk
==============================================================================
--- trunk/libs/proto/doc/proto.qbk (original)
+++ trunk/libs/proto/doc/proto.qbk 2011-12-17 14:44:03 EST (Sat, 17 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: trunk/libs/proto/doc/rationale.qbk
==============================================================================
--- trunk/libs/proto/doc/rationale.qbk (original)
+++ trunk/libs/proto/doc/rationale.qbk 2011-12-17 14:44:03 EST (Sat, 17 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: trunk/libs/proto/doc/reference/repeat.xml
==============================================================================
--- trunk/libs/proto/doc/reference/repeat.xml (original)
+++ trunk/libs/proto/doc/reference/repeat.xml 2011-12-17 14:44:03 EST (Sat, 17 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: trunk/libs/proto/doc/resources.qbk
==============================================================================
--- trunk/libs/proto/doc/resources.qbk (original)
+++ trunk/libs/proto/doc/resources.qbk 2011-12-17 14:44:03 EST (Sat, 17 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: trunk/libs/proto/example/calc2.cpp
==============================================================================
--- trunk/libs/proto/example/calc2.cpp (original)
+++ trunk/libs/proto/example/calc2.cpp 2011-12-17 14:44:03 EST (Sat, 17 Dec 2011)
@@ -60,7 +60,7 @@
: calculator_expression::proto_extends(expr)
{}
- BOOST_PROTO_EXTENDS_USING_ASSIGN(calculator_expression)
+ BOOST_PROTO_EXTENDS_USING_ASSIGN(Expr, calculator_expression<Expr>, calculator_domain)
// Override operator () to evaluate the expression
double operator ()() const
Modified: trunk/libs/proto/example/calc3.cpp
==============================================================================
--- trunk/libs/proto/example/calc3.cpp (original)
+++ trunk/libs/proto/example/calc3.cpp 2011-12-17 14:44:03 EST (Sat, 17 Dec 2011)
@@ -101,7 +101,7 @@
: base_type(expr)
{}
- BOOST_PROTO_EXTENDS_USING_ASSIGN(calculator_expression)
+ BOOST_PROTO_EXTENDS_USING_ASSIGN(Expr, calculator_expression<Expr>, calculator_domain)
// Override operator () to evaluate the expression
double operator ()() const
Modified: trunk/libs/proto/example/virtual_member.cpp
==============================================================================
--- trunk/libs/proto/example/virtual_member.cpp (original)
+++ trunk/libs/proto/example/virtual_member.cpp 2011-12-17 14:44:03 EST (Sat, 17 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