[boost] [egg] Review (at last)

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-04-17 19:16:25

[ 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.