Paul A. Bristow
[...]
For me, the killer argument for using Quickbook is the ability to use *code snippets*. These ensure that the bits of code you show have actually been through the (current) compiler.
That's what I currently do with Doxygen; all the snippets in the reference are taken from the example/ subdirectory of the project, and all those files are compiled and ran just like the other unit tests. It's really great.
I see no problems converting to Quickbook. Conversion is not too painful - especially if you have done it before.
However, I don't think you should worry about the docs now - they are fine for a review.
IMO your priority is to get some real-life users able to make an informed review.
Agreed.
Paul
PS For me, the library name is a big turn off - it doesn't say what the library does.
Heterogeneous combiNAtors. I agree the mapping is not as direct as, say, MPL, but it still beats Spirit, Phoenix and Proto (unless those are non-obvious acronyms).
And, for me, the names of functions are enough to condemn the library as unacceptable for Boost.
I have reasons to be uncomfortable with changing names in the library: - While names are inconsistent with the usual C++, they are consistent inside the library. Changing one name can break this consistency if I'm not careful. Further, there are names which just don't have a C++-friendly name, so I can't hope to change _all_ the names. We'll have to deal with either 100% FP names or 50% C++ / 50% FP, but 100% C++ just can't be done. - Some, C++ names imply some kind of mutation of the structure. Since Hana does not do any mutation, I must be careful not to choose a name that suggests something that's not the reality.
This really, really impressive and obviously really useful library is for C++ users, not Haskell users.
Louis