FC++ Formal review half way over today (ends 2/23)
Reminder: the formal review for the FC++ functional programming library is now at the half way point - only 5 days remain. If you have an interest in the FC++ library now would be a good time to prepare a review. It would be useful to hear your opinion even if you are not an expert in the functional programming domain or you don't know what a monad is. You are not required to spend a lot of time with the code (although it can be helpful). Some seed questions, in addition to the usual ones referred to below (and at <http://www.boost.org/more/formal_review_process.htm>): Can you understand the intent of the library from the documentation and example code? What are your ideas about the relationship between FC++ and existing boost components? Would some or all of the facilities FC++ (lazy lists, monads, lambda, "prelude") make a useful, relevant addition to boost? Why or why not? If not, do you believe that the author should rework parts of the lib for possible later acceptance? Individual reviews are an essential part of the review process, so please consider spending some time with FC++ this week and then post your thoughts. Thanks, Mat The original notice is reproduced below for your convenience. ### The formal review of fcpp by Brian McNamara and Yannis Smaragdakis is now in progress, running from Friday February 13th at 12 noon, PST and and run to Monday, February 23rd, 12 noon PST. The library is currently available at <http://www.cc.gatech.edu/~yannis/fc++/boostpaper/> Here is a brief introduction to the library: FC++ is a library for doing functional programming in C++. The library provides a general framework to support various functional programming aspects, such as higher-order polymorphic functions, currying, lazy evaluation, and lambda. In addition to the framework, FC++ also provides a large library of useful functions and data types. The main utility of the library comes from its ability to implement functional programming designs, especially those which use higher-order polymorphic functions or lazy evaluation in significant ways. The library also contains a number of ancillary components that implement features like currying and lambda for function objects; these features are also useful in their own right. For information about submitting a Formal Review, see <http://www.boost.org/more/formal_review_process.htm> Please try out the library and read the documentation and say whether or not you think the library should be accepted by Boost and why. Compiler notes: This library has been tested with icc7 and with gcc-3.1.1 (and various other gcc-3.x.y versions) on Solaris and Linux. The library is also likely to compile on VC++7.1 and Comeau (prior versions of the library succeeded with these compilers, but this particular snapshot has not been tested with them). The library covers a great deal of the C++ language and thus requires a high degree of standard conformance; compilers like gcc-2.95.x and VC++6 will not be able to compile the library. Getting started: The web page http://www.cc.gatech.edu/~yannis/fc++/boostpaper/ mentions all the basics: The zip file will expand into these subdirectories: fcpp/fcpp/ # the library (.hpp) files fcpp/fcpp_clients/ # the example (.cpp) files Running the examples just involves invoking the complier with the right #include paths; for example, # in the fcpp_clients directory g++ -I/path/to/boost -I../fcpp some_example.cpp There is also a gnu-style Makefile included with the clients (examples), which will compile all of the examples in batch (you will have to edit a tiny bit at the top of the Makefile). The examples in the clients directory are a mix of both (regression-type) tests cases which cover the features of the library and example applications which demonstrate some of the library's utility. The README file in the client directory gives a short explanation of some of the more interesting clients. The documentation at http://www.cc.gatech.edu/~yannis/fc++/boostpaper/ provides a walkthrough and reference for most of the main features of the library. There are also some pointers out to other papers and documentation on the main FC++ web site: http://www.cc.gatech.edu/~yannis/fc++/ Conformance to Boost guidelines: The library meets most of the requirements described at http://www.boost.org/more/lib_guide.htm Here are a few notable exceptions: - the current library headers are too "monolithic"; you #include "prelude.hpp" and suck in all of the library - some of the lambda internals should be rewritten to use MPL rather than hand-rolled metaprogramming code - only a few of the example programs utilize the Boost testing framework (to automate regression testing) Should the library be accepted into Boost, Brian will remedy these deficiencies. (If you notice other major problems along these lines, please bring them to Brian's attention during the review.) The Formal Review manager is Mat Marcus.
"Mat Marcus" <mat-boost@emarcus.org> wrote
It would be useful to hear your opinion even if you are not an expert in the functional programming domain
I am not much experienced with functional style of programming but in spite of this I think FC++ should be part of Boost ;-) IMO its documentation should be expanded: - every code snippet in tutorial should have link to small but complete example - feature description should contain performance impact: CPU/memory/template nesting requirements. - there should be page with links to all examples and their short description (btw. example file names aren't very informative). - it would be nice to have formal style reference documentation Substantial part of FC++ compiles with Intel C++ 7.0 (plugged into VC6 IDE), few found problems looks fixable. I informed author about details in private email. /Pavel
Would it be possible to extend the formal review of FC++ one week, considering it is an almost complete formal workspace for solving problems? [This also touches at one of the problems with it...] I have had some time to use it in a project of mine (#ifdef:ed to switch back to good old STL+Boost...) and love it, but ... I am not sure whether it fits the goals of Boost? And, I am a Haskell developer, as well, so I might be biased. So, if there is any chance of extending the review, this particular functional guy would be happy... /David
Would it be possible to extend the formal review of FC++ one week, considering it is an almost complete formal workspace for solving
"David Bergman" <davidb@home.se> escribió en el mensaje news:200402182319.i1INJr529113@heart-of-gold.osl.iu.edu... problems?
[This also touches at one of the problems with it...]
Yes, please.... I really like to make an in-depth review but it will take more time than currently given. Fernando Cacciola SciSoft
"Fernando Cacciola" <fernando_cacciola@hotmail.com> wrote in message news:c116qn$d89$1@sea.gmane.org...
Would it be possible to extend the formal review of FC++ one week, considering it is an almost complete formal workspace for solving
"David Bergman" <davidb@home.se> escribió en el mensaje news:200402182319.i1INJr529113@heart-of-gold.osl.iu.edu... problems?
[This also touches at one of the problems with it...]
Yes, please.... I really like to make an in-depth review but it will
take
more time than currently given.
I concur -- I'm only half-way through the source, and would like to absorb the whole thing before I make comments. A couple more days would be very helpful. Jonathan
This is just a quick appeal for more reviews along the lines of http://www.boost.org/more/formal_review_process.htm#Comments especially from those of you mentioned below. :) Thanks again to all those of you who have already contributed to the discussion; I have received many comments which will help improve the library in concrete ways, as well as just general ideas to mull over in the coming weeks and months. On Thu, Feb 19, 2004 at 02:34:18PM -0700, Jonathan Turkanis wrote:
"Fernando Cacciola" <fernando_cacciola@hotmail.com> wrote in message news:c116qn$d89$1@sea.gmane.org...
Would it be possible to extend the formal review of FC++ one week, considering it is an almost complete formal workspace for solving
"David Bergman" <davidb@home.se> escribi� en el mensaje news:200402182319.i1INJr529113@heart-of-gold.osl.iu.edu... problems?
[This also touches at one of the problems with it...]
Yes, please.... I really like to make an in-depth review but it will take more time than currently given.
I concur -- I'm only half-way through the source, and would like to absorb the whole thing before I make comments. A couple more days would be very helpful.
I think Fernando is off the hook (already posted a review), but I hope to see reviews from David and Jonathan as well. (Not to rush you or imply that you're obligated. But I'd appreciate it. :) ) -- -Brian McNamara (lorgon@cc.gatech.edu)
I think Fernando is off the hook (already posted a review), but I hope to see reviews from David and Jonathan as well. (Not to rush you or imply that you're obligated. But I'd appreciate it. :) )
Hi Brian, Have you seen my "formal" review from couple of days before? (there's the vote in there) I'd like to know your thoughts about the documentation issues I mentioned. And BTW, I'm working through the examples right now...- kind of difficult though since I found too many things undocummented. Fernando Cacciola SciSoft
On Thu, Feb 26, 2004 at 05:43:13PM -0300, Fernando Cacciola wrote:
Have you seen my "formal" review from couple of days before? (there's the vote in there) I'd like to know your thoughts about the documentation issues I mentioned.
Ok.
1) The documentation that comes with the boost version is not self contained. It refers to external documents (on the FC++), which AFAICT are required reading in order to know and understand all of the library. Most boost users would expect to get everthing they need in the download and they will be discouraged if they find out they need to pick additional documentation elsewhere.
Point taken, though I think the only "required reading" on the FC++ web site is the stuff on monads (which is one part of the library I am convinced does not yet deserve to be in Boost) and a couple of optimization things (involving odd_lists and reusers; these should be added to the Boost documentation, but you don't need to know about them to use the library). (Do you disagree?)
2) There are too many features which are underdocumented or not documented at all: they're just shown by example or merely mentioned. Examples are strict_list, the epilog functions, most of the special lambda stuff (let/letrec,LETtype....)
This I agree with. The strict_list example and the lambda stuff will be easy for me to remedy, I think (the interfaces are simple). Failing to document the Haskell prelude was an error on my part of the type you describe below.
In general, the documentation shows FC++ as a FP library "for functional programmers who want to do some C++" Most of the stuff ommited or barely mentioned are well know to FP programmers, but to most C++ programmers they are very obscure (LISP-derived languages keep on using short meaningless identifiers, and so does FC++)
It might be ok for FC++ itself to be targeted to FP programmers (after all, it is a functional programming library), but IMO Boost.FC++ should we presented the other way around: for C++ programmers who "don't know" functional programming "at all", but who are now given the oportunity the learn about it, as they apply the concepts and tools to everyday C++ programming, because of FC++.
If the documentation of FC++ is reworked with that goal in mind, given the reach of Boost, I guess a great deal of the C++ community will get to know the best of FP while keeping their (our) favorite language.
I agree. How sad--when I wrote the Boost documentation, I actually tried to make it "C++ audience oriented". While I think the Boost FC++ docs are an improvement over the stuff on the FC++ web site, I still apparently have a ways to go to describe the library in a "C++ friendly" way.
And BTW, I'm working through the examples right now...- kind of difficult though since I found too many things undocummented.
Indeed; keep in mind that The examples in the clients directory are a mix of both (regression-type) tests cases which cover the features of the library and example applications which demonstrate some of the library's utility. The README file in the client directory gives a short explanation of some of the more interesting clients. It was a mistake on my part to not make any clear delineation between "examples" and "tests". If you have questions, feel free to ask (me directly, or on the list); this won't address the documentation issue, but may at least help you understand some stuff better now. Thanks much for your extensive comments, and thanks again for your "formal" review message. -- -Brian McNamara (lorgon@cc.gatech.edu)
"Brian McNamara" <lorgon@cc.gatech.edu> wrote in message news:20040226075601.GA3173@lennon.cc.gatech.edu... This is just a quick appeal for more reviews along the lines of http://www.boost.org/more/formal_review_process.htm#Comments especially from those of you mentioned below. :) I think Fernando is off the hook (already posted a review), but I hope to see reviews from David and Jonathan as well. (Not to rush you or imply that you're obligated. But I'd appreciate it. :) ) I'm defintely planning on it. I'll try to do it tomorrow. Jonathan
Hi, This review is mainly based about the lambda part of FC++, as I've not had chance to have a proper look at the other parts (if I do before review period is over I'll add a 2nd review, but that is unlikely). I have no experience in Haskell or other functional programming languages. * What is your evaluation of the documentation? Seems fine and comprehensive. I think more motivating examples are required; it felt a bit abstract. * What is your evaluation of the potential usefulness of the library? I think Boost Lambda and FC++ lambda expressions are both about as ugly as each other, and the BLL versions seem to be a few characters shorter. So even if FC++ is accepted I will continue to use BLL. I am interested in the lazy-evaluation list, but cannot think of any code where I'd need it enough to justify the learning curve and the extra dependency. * Did you try to use the library? No. * How much effort did you put into your evaluation? About 2-3hrs reading docs and reading/writing mails. * Do you think the library should be accepted as a Boost library? No, simply as I personally have no need for it. Also it seems the more libraries in boost the longer it takes to get a regression-passing release out, so adding it just because it is clever and well-written is not a good enough reason in my opinion. Darren
At 06:32 PM 2/18/2004, Darren Cook wrote:
Also it seems the more libraries in boost the longer it takes to get a regression-passing release out,
That, together with the download size, are issues Boost will have to solve in order to grow. And we will solve those issues. We shouldn't start rejecting otherwise useful libraries because of them.
so adding it just because it is clever and well-written is not a good enough reason in my opinion.
Agreed, but if "useful" is added, and of course the other Boost qualifications are met, then "clever and well-written" look pretty good. (That's a general comment - I haven't looked at FC++ so have no opinion as to its usefulness.) --Beman
Hi Brian, Anyway, I just downloaded the boost version of FC++. I'm just beginning to read and peruse the code. As you surely know, FC++ has been one of my influences. I've studied the code once a few years ago in its early beginnings. And how it has grown! I still have a copy of FC++.1.2.1. I can't say enough how much it has influenced Spirit and Phoenix. Anyway, a quick question before anything else: How easy would it be to decouple the FC++.1.2.1 part of the library (i.e. without the lambda, without the sugar and spice)? If you recall, before Spirit became a boost library, I considered using FC++ in Spirit. One particular thing I liked was its small size. As a library writer myself, using another library, it seems more appropriate to hook into the lower level stuff, which in itself is already quite useful (I recall the exact reals library, for instance; certainly it was written prior to the sugar). I've seen you draw an outline of the basic organization of FC++ as it is now. Which part of this outline corresponds to the old FC++.1.2.1? << BTW, I haven't seen Yannis around in boost? >> Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On Thu, Feb 19, 2004 at 08:08:26AM +0800, Joel de Guzman wrote:
Anyway, a quick question before anything else: How easy would it be to decouple the FC++.1.2.1 part of the library (i.e. without the lambda, without the sugar and spice)? If you recall, before Spirit became a boost library, I considered using FC++ in Spirit. One particular thing I liked was its small size. As a library writer myself, using another library, it seems more appropriate to hook into the lower level stuff, which in itself is already quite useful (I recall the exact reals library, for instance; certainly it was written prior to the sugar). I've seen you draw an outline of the basic organization of FC++ as it is now. Which part of this outline corresponds to the old FC++.1.2.1?
Here is the high-level summary of what has changed since 1.2.1 (in roughly chronological order): - I did a performance pass, and applied a number of run-time optimizations (some of which were drastic improvements) - made the library really standards-compliant/portable - added many new library functions and a few new library datatypes - added new features (lambda/monads/infix) Lambda and monads are decoupled from the library; indeed right now they're "turned off" unless you explicitly say #define FCPP_ENABLE_LAMBDA somewhere. Other than that, the only thing that makes the current version "bigger" than old versions is the number of functions and datatypes you find in headers like "prelude.hpp". As I've already mentioned, I know these headers are too monolithic (if you just want one function, like "map", you are forced to #include about 70 other functions too), but that's easy to fix.
<< BTW, I haven't seen Yannis around in boost? >>
Yeah; he hasn't had the time/interest to participate. -- -Brian McNamara (lorgon@cc.gatech.edu)
Brian McNamara wrote:
Other than that, the only thing that makes the current version "bigger" than old versions is the number of functions and datatypes you find in headers like "prelude.hpp". As I've already mentioned, I know these headers are too monolithic (if you just want one function, like "map", you are forced to #include about 70 other functions too), but that's easy to fix.
Thanks! Refactoring the monolithic whole into chunks will definitely be a good thing. Anyway... I'm trying to get into the code and docs whenever I could steal some time. So, my comments may be fragmented. Pardon me. Here's one. In the docs, you say: (Now is a good time to mention that FC++ supports functoids of 0-3 parameters. The fullN, funN, and c_fun_type classes have only been defined for functions of up to three arguments.) Why only three? Experience with Phoenix with Spirit shows that this is not enough. Why hard-code the limit? I used to hate the preprocessor, but now, I always use boost.preprocessor to generate redundant code, hence, not having a hard coded arity limit. Is there a technical problem not to support more? I might be missing something significant though. But I recall that this is also one thing I didn't like when I first reviewed FC++ a few years ago (I was also hindered by LL's limit of 10, IIRC). Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Anyway... I'm trying to get into the code and docs whenever I could steal some time. So, my comments may be fragmented. Pardon me.
Here's another: BOOST_FCPP_DEFER_DEFINITIONS Setting this flag makes all the functoids get declared as "extern" variables, but not defined. You then need to link against a separate object file with the definitions. Use this when you are using FC++ in mutiple translation units, and you do not want each TU to have its own copy of all the functoids. Why is this needed? Why not just make them const and forget about linker errors with multiple translation units? I see code such as: namespace impl { struct XPlus { template <class T, class U> struct sig; template <class T> struct sig<T,T> : public fun_type<T> {}; template <class T> T operator()( const T& x, const T& y ) const { return std::plus<T>()( x, y ); } }; } typedef full2<impl::XPlus> plus_type; /** open namespace...**/ plus_type plus; /** close namespace...**/ which, when BOOST_FCPP_DEFER_DEFINITIONS is defined: plus_type plus; IMO, this is not necessary. You can simply write: plus_type const plus; and get rid of linker errors on multiple translation units. <<BTW, mutiple is a typo>> Oh, and BTW, there's a significant disadvantage of FC++'s definition of plus compared to LL (and Phoenix). I notice that there is no return type deduction and both arguments are of the same type. Hence, it's not very friendly to C++'s rich set of types (numeric and others). IMO, T operator()( const T& x, const T& y ) const is simplistic and wrong. It should be: result_of_plus<X, Y>::type operator()(const X& x, const Y& y) const Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
which, when BOOST_FCPP_DEFER_DEFINITIONS is defined:
plus_type plus;
ooops... that should be: extern plus_type plus;
IMO, this is not necessary. You can simply write:
plus_type const plus;
Pardon..., that should be: plus_type const plus = plus_type();
and get rid of linker errors on multiple translation units.
... okidoke, that's all for today... Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On Thu, Feb 19, 2004 at 11:46:48PM +0800, Joel de Guzman wrote:
BOOST_FCPP_DEFER_DEFINITIONS
Why is this needed? Why not just make them const and forget about linker errors with multiple translation units?
Cool; I didn't realize this. I have been wanting to get rid of the DEFER_DEFINITIONS stuff, and you have shown me how. Thanks!
Oh, and BTW, there's a significant disadvantage of FC++'s definition of plus compared to LL (and Phoenix). I notice that there is no return type deduction and both arguments are of the same type. Hence, it's not very friendly to C++'s rich set of types (numeric and others). IMO,
T operator()( const T& x, const T& y ) const
is simplistic and wrong. It should be:
result_of_plus<X, Y>::type operator()(const X& x, const Y& y) const
This is probably a good idea; I hadn't considered this component when I was integrating other Boost stuff into FC++ to prepare for the review. -- -Brian McNamara (lorgon@cc.gatech.edu)
On Thu, Feb 19, 2004 at 11:04:16PM +0800, Joel de Guzman wrote:
Here's one. In the docs, you say:
(Now is a good time to mention that FC++ supports functoids of 0-3 parameters. The fullN, funN, and c_fun_type classes have only been defined for functions of up to three arguments.)
Why only three? Experience with Phoenix with Spirit shows that this is not enough.
Experience with FC++ has shown that it is enough. But I suppose it all depends on what domains/problems you are working on. :)
Why hard-code the limit? I used to hate the preprocessor, but now, I always use boost.preprocessor to generate redundant code, hence, not having a hard coded arity limit. Is there a technical problem not to support more?
Probably not; I just have not done the work. (There are only so many hours you can spend "boostifying" before you decide it's time to stop and put the library up for review.) (Actually, if you look at the code for "full3" http://www.cc.gatech.edu/~yannis/fc++/FC++.1.5/full.h I am not sure that the currying stuff can be so easily macro-ized. But maybe.)
I might be missing something significant though. But I recall that this is also one thing I didn't like when I first reviewed FC++ a few years ago (I was also hindered by LL's limit of 10, IIRC).
10! Except for code-generators, or people working in very specific domains, it's hard for me to imagine 10 not being enough. Wow! -- -Brian McNamara (lorgon@cc.gatech.edu)
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Brian McNamara Sent: Thursday, February 19, 2004 10:46 AM To: Boost mailing list Subject: Re: [boost] FC++ Formal review half way over today (ends 2/23)
Here's one. In the docs, you say:
(Now is a good time to mention that FC++ supports functoids of 0-3 parameters. The fullN, funN, and c_fun_type classes have only been defined for functions of up to three arguments.)
Why only three? Experience with Phoenix with Spirit shows
On Thu, Feb 19, 2004 at 11:04:16PM +0800, Joel de Guzman wrote: that this is
not enough.
Experience with FC++ has shown that it is enough. But I suppose it all depends on what domains/problems you are working on. :)
Why hard-code the limit? I used to hate the preprocessor, but now, I always use boost.preprocessor to generate redundant code, hence, not having a hard coded arity limit. Is there a technical problem not to support more?
Probably not; I just have not done the work. (There are only so many hours you can spend "boostifying" before you decide it's time to stop and put the library up for review.)
(Actually, if you look at the code for "full3" http://www.cc.gatech.edu/~yannis/fc++/FC++.1.5/full.h I am not sure that the currying stuff can be so easily macro-ized. But maybe.)
It looks like it would be pretty easy. Do you want me to do it for you? Regards, Paul Mensonides
On Thu, Feb 19, 2004 at 04:59:07PM -0800, Paul Mensonides wrote:
Brian wrote:
On Thu, Feb 19, 2004 at 11:04:16PM +0800, Joel de Guzman wrote:
Why hard-code the limit? I used to hate the preprocessor, but now, I always use boost.preprocessor to generate redundant code, hence, not having a hard coded arity limit. Is there a technical problem not to support more?
Probably not; I just have not done the work. (There are only so many hours you can spend "boostifying" before you decide it's time to stop and put the library up for review.)
(Actually, if you look at the code for "full3" http://www.cc.gatech.edu/~yannis/fc++/FC++.1.5/full.h I am not sure that the currying stuff can be so easily macro-ized. But maybe.)
It looks like it would be pretty easy. Do you want me to do it for you?
If this is not a burden for you, Sure! I'd love to learn more about this preprocessor stuff. else Let's wait for the results of the review. -- -Brian McNamara (lorgon@cc.gatech.edu)
Brian McNamara wrote:
On Thu, Feb 19, 2004 at 11:04:16PM +0800, Joel de Guzman wrote:
Why hard-code the limit? I used to hate the preprocessor, but now, I always use boost.preprocessor to generate redundant code, hence, not having a hard coded arity limit. Is there a technical problem not to support more?
Probably not; I just have not done the work. (There are only so many hours you can spend "boostifying" before you decide it's time to stop and put the library up for review.)
(Actually, if you look at the code for "full3" http://www.cc.gatech.edu/~yannis/fc++/FC++.1.5/full.h I am not sure that the currying stuff can be so easily macro-ized. But maybe.)
I might be missing something significant though. But I recall that this is also one thing I didn't like when I first reviewed FC++ a few years ago (I was also hindered by LL's limit of 10, IIRC).
10! Except for code-generators, or people working in very specific domains, it's hard for me to imagine 10 not being enough. Wow!
Yep, code generators! Especially, template code generators. This is typical if your library's client is another template library. Consider the (proposed) Spirit grouping (ala YACC) syntax: r = (a >> b >> c >> d >> e) [ f(_1, _3, _5) ]; Even this trivial example requires an arity of 5, regardless if only _1, _3, and _5 are actually used by the client. -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
participants (3)
-
Beman Dawes -
Brian McNamara -
Darren Cook -
David Bergman -
Fernando Cacciola -
Joel de Guzman -
Jonathan Turkanis -
Mat Marcus -
Paul Mensonides -
Pavel Vozenilek