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 | Monads 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: Direct Functoids 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. Full Functoids All the syntax niceties, like currying, infix, lambda's []/%. Indirect Functoids Very much like boost::function. Lambda and Monads Just that. Not yet proven "useful". Lists 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@cc.gatech.edu)