From: Brian McNamara (lorgon_at_[hidden])
Date: 2004-02-17 00:23:35
On Mon, Feb 16, 2004 at 09:31:52PM -0500, Jim Apple wrote:
> Here's a laundry list of complaints. After having read the
> documentation, I think FC++ is a great idea, but I don't think it's
> boost-compatible yet.
Some good food for thought here...
> This library is difficult to review because it is so large. Perhaps it
> could be split into
> 1. Functoids, including currying and thunks
> 2. Lists
> 3. Lambda
> 4. Monads
> I realize there is some overlap, but it could help with making
> everything more understandable. For instance,, presently, boost::lambda
> objects can be converted to boost::function objects. These could be one
> library, but I think they're quite nice as is.
It occurs to me only now that it would be really useful to have a
"conceptual dependency hierarchy", since this will compartamentalize
the library into more manageable sub-chunks. Let's see if I can
generate one now:
Direct Functoids Lists
/ / | \ \ |
/ / | \ \ |
/ / | \ \ |
Lambda Full Misc Lib Indirect List Library
| Functoids Functions Functoids Functions
| and Datatypes
In practice, there are a number of non-obvious implementation
dependencies among these chunks (some of which are more easy to
eliminate than others).
Here is also the capsule summary of what each part contributes:
Result type computation ("typeof"). The std::result_of has now
become the standard way to do this.
Practically everything depends on this, as you can't do
higher-order polymorphic functions without a mechanism for
computing return types.
All the syntax niceties, like currying, infix, lambda's /%.
Very much like boost::function.
Lambda and Monads
Just that. Not yet proven "useful".
List data structures. Useful in the functional sense (cons() and
tail() are O(1)). Provides one easy way to do lazy evaluation.
Misc Lib Functions/Datatypes
Lots of useful operator-functoids and combinators.
Also some datatypes, like maybe and by_need.
List Lib Functions
Lots of functoids that work on lists.
The last three are the bulk of the "library", whereas the rest are
more "framework". It might be more manageable to consider each of
these categories individually. (Perhaps I could/should start seven
separate email threads--one for each category. Good/bad idea, anyone?)
> I'm concerned about documentation that says "Look at the Haskell Report."
Concerned from the "Brian is too lazy to provide ample documentation"
standpoint, or something more?
Regarding your comments about names of various entities: I am willing to
change names if people find other names more attractive.
-- -Brian McNamara (lorgon_at_[hidden])
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk