[ sorry for the delay, it was general election time here in Italy and I had to return home for voting ] - What is your evaluation of the design? Good. I think that the overall structure is pretty good (see the thread between me and the author). I did have reserves on some details, but the author tried to clarify most of my doubts. I still have some problems with some minor parts: * nestN: I still do not understand how this works. It certainly isn't more readable than bind expressions. It should dropped from egg, redesigned or simply relegated as an implementation detail. * Pipable functions: I think that the pipability details in egg are too convoluted. The Pipable and Ambi concepts are a little fuzzy, and the latter badly needs a better name. Personally I think that the '|' operator should perform functional composition (and treat non callable objects as if they were stubs), but I do not think that this view is popular. Most uses of the pipe operator for pipelines are similar to the usage in egg. * Most higher order functions and builders in egg can be used in pure type expressions using result_of without nee to provide the runtime counterpart. This is very useful if your functions are stateless, but I think that using the result_of syntax plus the static_ for this purpose is not very intuitive. I would prefer an approach with pure mpl meta-functions. Most of the quirks of egg (like the MajorFunctionObject concept, which is simply PolymorphicFunctionObject, except that it works with lambda), could be fixed with helps from other boost libraries: Lambda should be result_of compatible, both using result_of to deduce result types of user function objects and also using the result<> protocol for its own function objects. Also it would be great if both boost.bind and boost.lambda closures where default constructible (to a singular value maybe?) and, in the case of lambda, assignable (which would eliminate the need for the 'regular' wrapper. - What is your evaluation of the implementation? I didn't specifically take a look at it. I know that the author took great pains to make it work on as many compilers as possible (and workarounding more than one compiler bug) - What is your evaluation of the documentation? I think that the documentation is the only major problem of the library. IMHO one of the biggest (if not the biggest) selling point of Boost is the high quality of its documentation. Egg documentation is definitely not on par. In particular: * The quick start section reads simply as a showoff of some of the features of the library. It doesn't really explain anything. All the magic is still hidden. Also it covers only some part of the library and the examples are pretty arcane. It really need to show real life use cases and give a step by step explanation of all the features used. * The reference documentation is too formal. It is very hard to understand the formalism used, (and the lack of a true tutorial doesn't help of course). There is too much use of (obscure) examples and 'valid expressions', and often a clear explanation in English of what a function does is lacking. * It shows that the author is not an English speaker, but I think that many native speakers in the boost community can lend an hand here - What is your evaluation of the potential usefulness of the library? Very useful, at least if you take a functional approach to C++ and need polymorphic function object. I think that it would work very well when used with libraries like Fusion, Spirit, Proto and of course, Lambda that make great use of polymorphic function objects. - Did you try to use the library? Not as much as I wanted. I run the test suite and played around with the examples. - With what compiler? # g++ -v Target: i486-Linux-gnu Configured with: ../src/configure Linux gnu Thread model: posix gcc version 4.3.0 20070414 (experimental) - Did you have any problems? Most of the test suite compiled even if with many warnings (mostly due to "type qualifiers ignored on function return type"). Few tests ICEd the compiler. I think that the cause is that this compiler is very recent and egg hasn't been tested with it yet or maybe because it is an experimental snapshot of gcc. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? An in-depth study of the documentation. I didn't study the implementation directly, the author explain a good part of it to me. - Are you knowledgeable about the problem domain? Yes, I have written a library somewhat similar to egg. - Please always state in your review, whether you think the library should be accepted as a Boost library! Yes, but only after a mini review of the documentation only. I believe that the author will be able to come up with an excellent documentation. - Final comments Unfortunately I think that with so few reviews (just mine for now?), the library will have an hard time getting into Boost at this time. Probably the author didn't do a good job at selling it, even if many expressed interest in the past. If the library were to be rejected, I think that the author should resubmit a just a subset of it for inclusion, which would have a far greater chance to be appreciated and evaluated in a short time. This subset, IMHO, should concentrate on stateless function objects and should at least contain: * 'poly' which is a very convenient way to write polymorphic function * 'compose', 'curryN' and 'lazy' especially if, in addition to the higher order functions, the corresponding mpl metafunctions are provided to build polymorphic function objects types (without passing via result_of). * 'always', 'identity', and 'apply' are generally useful and simple enough that can go in the "basic package". Other advanced features, like pipability and infix notation (I like this one!) could then be evaluated once the basic functionality has been sold :). So should more hard-core functional capabilities like memoization and the fix point combinator. Support for static initialization of function objects could also come in a second time.