Stuff

[joergbrech]

• 0. Try what syn can take care of and how the performance compares to xpr
• 1. Document fold module with examples
• 2. Add convenience types to get the Xpr type of operations, e.g. OutputOfAdd<Term<u32>, Term<u32>>
• Add an example where a terminal is replaced by another expression, e.g. of type OutputOfAdd<Term<u32>, Term<u32>>
• 3. Think about terminals of references and lifetime consequences. This should be supported for the library to be useful! Maybe adapt the vector expression example accordingly.
• 4. More tests
• 5. Properly check and document zero-cost abstraction: Using xpr should ideally result in the same assembly as doing everything by hand thanks to compiler optimization - at least for moderately sized expression trees. See also https://www.boost.org/doc/libs/1_74_0/doc/html/boost_yap/manual.html#boost_yap.manual.object_code
• 5 1/2: Maybe add a hello world like SIMD example?
• 6. Allow folding of other expressions than just Terminals. Can we have default implementations without specialization?
• 7. Allow Folding of expressions, that have terminals of different types, e.g. Xpr::new(true) + Xpr::new(5) + Xpr::new("hello"). Currently I don't think this is possible without specialization...
• 8. Once 1 - 7 are done, we can add more operations, probably using helper macros.
• 9. Check examples of boost::yap. What can boost::yap do that xpr can't? What needs to be done to support this functionality?
• 10. Add a trait Expression with just one associated type Output and implement this for all Xpr<T> where T is Foldable by Evaluator such that Output is <Self as Foldable<...>>::Output. In addition, provide a type definition
  type ExpressionOf<X,T> = <Xpr<T> as Expression>::Output
  for convenience. The trait and type definition can be used to query the return types of expressions at compile time. This is useful for folding operations other than terminal and probably only makes sense as soom as mixed terminal expressions are supported (see previous bullet point)