[boost] FC++ formal review

From: Jaakko Jarvi (jajarvi_at_[hidden])
Date: 2004-03-02 00:36:44

This is my review for FC++:

I consider being knowledgeable of the domain, and
have followed the library since its early stages.
I've reviewed the libary (or related papers) before for other purposes,
and still consider the design sound.

I sing along the choir regarding the documentation: needs improvement.
Current documentation is somewhere in between a tutorial and a reference
manual, but is really currently neither.

Some of the concerns on this list have been
overlap with other libraries, such as boost::function, BLL and bind.

Regarding the lambda part of FC++, the scoped lambdas, with letrecs
etc. are more readable than the BLL counterparts on complex
lambda expressions, and there may be lambda functions that FC++ can
extpress but BLL can't (and vice versa I guess).

The lambda syntax with all the %plus% ^minus^ _*_ is very inventive
but almost too cute (personal opinion).
It is a bit disturbing that boost will have
different lambda syntaxes, with slightly different semantics
(e.g. currying is different, FC++ takes all args as const&, ...).

(As a side note, if I remember correctly,
BLL had currying, but it was dropped after complaints during BLL review.)

I do not have a clear answer what to do about the issue with different
syntaxes in boost. The BLL syntax/semantics is not the
final answer, nor is FC++ syntax/semantics. We know much more about
expression templated lambda implementation techniques/syntax options/...
now compared to when, say BLL, was designed, and I'm assuming FC++ too.
I'm hoping all the knowledge will eventually converge into a unified
syntax / semantics (or then get wiped out by built-in lambdas).
This is not reality at the moment, and is no reason to reject FC++ today.
The best option for now, as I see it, is to live with different
approaches in boost, and gradually work towards a common
lambda syntax --- and understand that it will mean deprecating some of the
syntaxes in the future.

There are other concerns:

Some more work need to be put into the
library, especially the docs, to make FC++ a model-citizen for boost.
The monolithinc includes should be broken into smaller chunks.
It may be a bit of an investment for a new user to learn FC++, and a
new user may fail to see the reason why one should (docs again:).

FC++
may never be the first thing to #include to create function objects
for STL algorithms, but I believe it can be a building block for
powerful abstractions (Joel alluded to some already, FC++ docs point
out exact reals). Lazy lists will probably find a lot of uses.
In addtition, FC++ has a significant educational value
(or can have, with improved docs :)

As is common with software, all the feedback one gets is negative
(no news is good news), so the issues I did not touch in my review
(such as overall design, implementation quality) I found to be fine.
(So Brian, on the contrary to how the review may read,
I really think very positively about the library!)

I vote for including FC++ into boost.

  Jaakko

--
-- Jaakko Järvi                       email: jajarvi_at_[hidden]
-- Post Doctoral Fellow               phone: [phone]
-- Pervasive Technology Labs          fax:   [phone]
-- Indiana University, Bloomington
--------------------------------------
Here's a list of detailed comments on the docs for Brian:
7.1 Is the result of currying a full functoid a full functoid?
Or just a functoid?
7.5. C++ will eventually have a typeof operator...
It is likely that the operator is called something else than 'typeof',
so maybe something like:
... will eventually
have an operator for querying the type of an expression ...
10.6.
Instead of &cout ^out_stream^ x, how about make streaming work with
boost::ref(cout) ^out_stream^ x.
12.1.
Lambda's are nice but there are a few uglinesses.
if0, if1, if2  seems quite hackish.
The _*_ argument for thunks is ugly too.
maybe g[void_]
Errors like lambda(X)[ f[1, 2, x]] will be very hard to spot
(I'm assuming the compiler does not catch it)
Using == in let bindings is confusing (I know it is not an assignment
but it's still more like an assignment than equality comparison).
Or is there a precedence issue?
13. Monads
Maybe postpone for later submission.