I put about a day into looking at FC++ (reading the papers, trying to write some small examples). I didn't have a lot of success -- partly because it has been quite a while since I last programmed in a functional language, and partly because the documentation needs serious work. Therefore, I don't have a full review to provide. Much like the serialization library, I think that this is an ambitious and important library that isn't ready to pass a Boost review on its first time around. If the author is up to it, then I'm sure further work will get it there. Re argument limit of 3: I'm a bit surprised that this has never been a problem. Seeing what boost::preprocessor can do for you is probably a good idea. Naming nit-picks: "Functor" has for years been commonly used to mean "function object" (in addition to its original meaning from category theory). [http://www.dre.vanderbilt.edu/~bala/c++-function-objects.pdf; http://www.sgi.com/tech/stl/functors.html; http://en.wikipedia.org/wiki/Functor]. Have no referees of your academic publications brought this up? There is no need to name anew a common concept: therefore, s/functoid/functor globally! (Global search and replace is your friend. :-) A list type is already present in ::std, and means something different. Perhaps lazy_list, or (cringe) llist. Follow the C++ standard's practice for variable naming, e.g. TheActualTypeOfTheLambdaExpressionIsNotConvertibleToItsGivenType should be the_actual_type_of_the_lambda_expression_is_not_convertible_to_its_given _type (example from lambda.hpp)
On Mon, Mar 01, 2004 at 02:56:38PM -0700, Dave Gomboc wrote:
I put about a day into looking at FC++ (reading the papers, trying to
Thanks for taking the time, and thanks for your comments. A couple quick replies:
"Functor" has for years been commonly used to mean "function object" (in addition to its original meaning from category theory). [http://www.dre.vanderbilt.edu/~bala/c++-function-objects.pdf; http://www.sgi.com/tech/stl/functors.html; http://en.wikipedia.org/wiki/Functor]. Have no referees of your academic publications brought this up? There is no need to name anew a common concept: therefore, s/functoid/functor globally!
I don't recall this comment coming up from referees of the publications. Note that, to the FP community, "functor" means something completely different from what it means in C++. In any case, "functoids" as described in those papers were a "new concept" requiring a new name. A "functoid" was a "functor" that also supported polymorphic return-type deduction. This distinction is now becoming dated, though. In any case, the overall point here (that the Boost documents on FC++ need to be tailored to a C++ audience, rather than an FP audience) is taken.
[various stuff about names/naming elided]
I have no objections to renaming various entities in the library, and have received a number of good suggestions from many of you these past two weeks. If the library is accepted, I'll try to consolidate the suggestions and make the most commonly-requested changes. -- -Brian McNamara (lorgon@cc.gatech.edu)
Brian McNamara wrote:
"Functor" has for years been commonly used to mean "function object" (in addition to its original meaning from category theory). [http://www.dre.vanderbilt.edu/~bala/c++-function-objects.pdf; http://www.sgi.com/tech/stl/functors.html; http://en.wikipedia.org/wiki/Functor]. Have no referees of your academic publications brought this up? There is no need to name anew a common concept: therefore, s/functoid/functor globally!
I don't recall this comment coming up from referees of the publications. Note that, to the FP community, "functor" means something completely different from what it means in C++.
In any case, "functoids" as described in those papers were a "new concept" requiring a new name. A "functoid" was a "functor" that also supported polymorphic return-type deduction.
This distinction is now becoming dated, though. In any case, the overall point here (that the Boost documents on FC++ need to be tailored to a C++ audience, rather than an FP audience) is taken.
A "signed functor" ??? :-) -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Dave Gomboc wrote:
A list type is already present in ::std, and means something different. Perhaps lazy_list, or (cringe) llist.
Disagree. MPL has list and vector. I'd hate to see it named it differently. mpl::slist (static-list)? Yuck!
Follow the C++ standard's practice for variable naming, e.g. TheActualTypeOfTheLambdaExpressionIsNotConvertibleToItsGivenType should be the_actual_type_of_the_lambda_expression_is_not_convertible_to_its_given _type (example from lambda.hpp)
Agree! -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Ok, I am an FP guy, since the mid 80's. I love Haskell and the way I can formalize problems in Haskell (and similar frameworks.) I have *not* used FC++ before. Off to the review. What is your evaluation of the design? -------------------------------------- The design follows Haskell, and the Prelude library, quite well. Most things are there. It is hard to abstract Haskell, and FP in general, from the picture. I.e., to judge the design from a non-FP point of view. An attempt would probably yield the design to be awkard. The names are a bit weird. First of all, I do not like "functoid" since it is often used as a synonym to "function object or regular function, i.e., anything that can be applied." Second, the "direct", "indirect" and "full" classifications of functoids do not reveal their meaning to me. Especially not "full functoid." I would love to see a "lazy_function" and "lazy_list," actually. Or, go the "closure" route in terminology and viewpoint. I.e., make the "laziness" explicit, since it is *not* a (wanted or not) side effect of a non-strict semantics, as some hard-core FPers view the world. I view the functoids of FC++ as closures, capable of acting as functions of any arity, i.e., partially currable. Judgment: awkward from a C++ point of view and bad names for the constituents. True to The Original, though ;-) What is your evaluation of the implementation? ---------------------------------------------- The implementation is very good. The best of C++ meets the best of Haskell. What is your evaluation of the documentation? --------------------------------------------- Much better than most people have argued. At least for an FP aficionado. What is your evaluation of the potential usefulness of the library? ------------------------------------------------------------------- The potential is great, but it *is* a complete framework, i.e., you either buy the whole package or nothing. This is quite non-Boostish. I would love to see parts of it create new libraries that can integrate with Boost, such as "lazy_list" or "closure" (functoid.) I would love to use it, but I know that I would then have to abandon "C++" for that project and buy into "FC++." The upside of having FC++ part of Boost would be that I can "legally" use it in my projects, where the customer allows for Boost ;-) Did you try to use the library? With what compiler? Did you have any problems? ---------------------------------------------------------------------------- ---- Yes, I tried it with VC 7.1, and had no problems. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? ---------------------------------------------------------------------------- ---------------- In-depth study, but did unfortunatley not have time to code that much against the framework. Are you knowledgeable about the problem domain? ----------------------------------------------- Yes, very. Do you think the library should be accepted as a Boost library? --------------------------------------------------------------- This is a hard one. I would love to use, and give some feedback to, FC++. I do not see how it fits in the Boost suite, though. It is too "functional" ;-) Seriously, it is too much of a monolithic framework. Judgment: I think FC++ should *not* be accepted.
"David Bergman" <davidb@home.se> writes:
What is your evaluation of the potential usefulness of the library? -------------------------------------------------------------------
The potential is great, but it *is* a complete framework, i.e., you either buy the whole package or nothing. This is quite non-Boostish. I would love to see parts of it create new libraries that can integrate with Boost, such as "lazy_list" or "closure" (functoid.)
I challenge the assumption here. The beauty of DSELs like FC++ is that they *do* integrate smoothly with other libraries written in the host language. FC++ can be used to make new function objects; it can also call existing function objects. How much more interoperable do you want it to be? -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (5)
-
Brian McNamara -
Dave Gomboc -
David Abrahams -
David Bergman -
Joel de Guzman