Specifically,
(1) We now benchmark with fusion::list too
(2) We now document our methodology for forcing the evaluation of algorithms
Note that we still use `as_list` and `as_vector` to force the evaluation
of algorithms instead of using e.g. `for_each`. This is because we want
to compare apples with apples, and for this we need to get a sequence of
computed values, not only for_each over the view. The disclaimer in the
tutorial saying "Fusion might encourage a different design" takes care
of warning people about the fact that we're not necessarily using
idiomatic Fusion, but not need to benchmark unfairly to try to
account for that.
Precisely,
1. Rename hana::_type to hana::basic_type, and document it
2. Rename hana::type<> to hana::type_c<>
3. Create and document the hana::type<> type
- Allow specializing models_impl with a forward declaration only
- Modularize remaining concept headers
- Include <boost/hana.hpp> in unit tests to ease the transition
- Add the core/dispatch.hpp header to reduce the number of boilerplate includes
- Write sections on containers, algorithms, and runtime performance
- Make sure examples consistently use 2 space tabs
- Disable -Wunused-parameter for examples
- Resolves#70
The requirement of pure functions is now documented.
- Resolves#14
It turns out that the benefits of specifying the type of containers
seems to be essentially limited to pattern matching. This is not
enough to justify all the bad things it brings, especially
considering the fact that recursion (currently the only use
case for pattern matching) forces the creation of a new tuple
at each step, which is disastrous. The unspecified-ness of the
container's type is now documented.
