1[section Rationale] 2 3[heading Decaying Values Captured in YAP Expressions] 4 5The main objective of _yap_ is to be an easy-to-use and easy-to-understand 6library for using the _et_ programming technique. 7 8As such, it is very important that the way nodes in a _yap_ expression tree 9are represented matches the way nodes in C++ builtin expression are 10represented. This keeps the mental model for how to identify and manipulate 11parts of expression trees consistent across C++ builtin and _yap_ trees. 12 13Though this creates minor difficulties (for instance, _yap_ terminals cannot 14contain arrays), the benefit of a consistent programming model is more 15important. 16 17 18[heading Reference Expressions] 19 20_yap_ expressions can be used as subexpressions to build larger expressions. 21_expr_ref_ exists because we want to be able to do this without incurring 22unnecessay copies or moves. Consider `v2` and `v3` in this snippet from the 23Lazy Vector example. Each is a terminal that owns its value, rather than 24referring to it. 25 26 lazy_vector v2{{std::vector<double>(4, 2.0)}}; 27 lazy_vector v3{{std::vector<double>(4, 3.0)}}; 28 29Now consider this expression: 30 31 double d1 = (v2 + v3)[2]; 32 33Without using reference semantics, how can we capture this expression, even 34before evaluating it, without copying or moving the vectors? We cannot. We 35must take references to the `v2` and `v3` subexpressions to avoid copying or 36moving. 37 38This comes at a cost. Dealing with _expr_ref_ expressions complicates user 39code. The alternatives, silently incurring copies/moves or disallowing the 40use of subexpressions to build larger expressions, are worse. 41 42 43[endsect] 44