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
Using a function instead of a variable template allows us to provide an
optimized version for hana::tuple more easily. It also fixes some issues
on GCC.
Of the xxx_exactly variants, only drop_front_exactly is kept for now,
because it actually allows an optimization. The other ones did not
really provide a compile-time improvement, so they are removed.
Also:
- Remove the boost_hana_add_executable function, which is now useless
- Properly set the LD_LIBRARY_PATH to link against a custom libc++
- Adjust the Travis build
Fixes#135
- Make sure the check.benchmarks are serialized
- Run Doxygen with Clang 3.6 instead of Clang trunk
- Download prebuilt Doxygen instead of building from source
- Run unit tests on two cores
- Extend the Quick Start with more small examples, and then the large
switchAny example.
- Add clarifying remarks right in front of the CheatSheet for skimmers.
Damn skimmers.
- Benchmark the compile-time of creating std::array
- Remove the preface entirely
- Move the current introduction to a "Description" section
- Move the "Quadrants of computation" to the "Introduction"
- Move the current "Motivation" section to the start of the "Introduction"
- Move the section on "Introspection" higher up in the docs
- Remove the "Concept" column in the Cheatsheet, and add links to each
individual algorithm instead.
- Add a rationale for unpack's name and parameter order
- Add `fold` and `reverse_fold` to the cheatsheet
- Mention the list of all headers in the tutorial
- Add an alphabetical index with everything in the library
- Precise that smaller is better in chart subtitles
- Add benchmarks for std::make_tuple and std::get
- 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.
- Rename fold{l,r,l1,r1} to fold.{right,left} with overloads.
- Rename foldlM/foldrM to monadic_fold.{left,right}
- Add no-state variants of the monadic folds
- Improve the fold's documentation
- Deprecate the previous folds; they'll be removed soon
Fixes#18.
This essentially undo parts of 307d3d0. While it seemed a like good
idea to over-modularize type classes to reduce header dependencies, I
think it was a mistake. What 307d3d0 did was basically split each of
the components of a type class into a single header (typeclass/operators.hpp,
typeclass/mcd_1.hpp, typeclass/mcd_2.hpp, ...).
At first, it resolved many weird header dependency glitches. However, it
also made everything more complex; creating even easy type classes was
sometimes much longer than it should have been, and using type classes
was tricky because you had to know exactly what to include. It also went
against the idea of implicit type class instances being provided whenever
that's possible, which I think is a nice feature of the library. Being
dissatisfied with this, I opted for a simpler header organization with
a fwd/ directory that contains forward declaration headers, and everything
else in the same directory.
A possible objection to this change would be that you are now forced
to include sometimes more than what you strictly need when e.g. defining
an instance or using only some instance(s) of a data type. My answer to
this is that Hana is a really small library and the parsing is not
going to have a huge impact on overall compilation time. My bet is that
the time that will be saved by programmers with a simple header hierarchy
outweights the parsing time by far.
