----- Original Message -----
I can only say that I'd like to see library like that in boost but I'm afraid this is not my decision. Thank you, Piotr. It appears there is no such interest, at the moment.
Specific to here and now, I assume that the migration to github is occupying a lot of spare cycles in the community. In my opinion, memoization seems like a useful capability. I have no particular application for it on my to-do list, but having used memoization in prolog before, it seems like the sort of thing I might someday find myself wishing were in boost. IMO, proposals like this fall into a certain category, that might get less traction because if you randomly selected 1000 programmers, only a handful (at most) would have an application needing the proposed library. I think my current proposal for edit_distance/edit_alignment is also in this category. So is the handful of 'tree' proposals. Most applications simply don't need it Finding the people with the right combination of knowledge/interest in Boost, plus the domain knowledge to give good feedback, is tricky. And yet... when you want it, you want it :) I'm not sure what the answer to that quandary is. It's not like boost has none of these. Quaternion/Octonion come to mind as an example. I've seen other projects (e.g. octopress) that maintain a page of "notable 3rd-party contributions", that aren't in the official project, but can be used as a resource for people interested in capability-X that isn't in the official distribution. Alternatively, the new github library organization will allow for people to maintain customized library forks, so that is a possible avenue. For example, once the dust clears, I could fork boost::algorithm and maintain my own version that includes edit_distance. Periodically merge in the official version, etc.