- Boost - lists.boost.org

RE: [boost] Re: FC++ formal review
by Rozental, Gennadiy 02 Mar '04

02 Mar '04

> > Actually the point of my remark is that would we be able to > write meta > > programs in imperative style instead of FP style > compilation would be > > much faster. > > The slowness of metaprogram compilation has almost *nothing* > to do with the FP style of metaprogramming, and almost > everything to do with the accidental nature of the > metaprogram evaluation engine (using template instantiation). And why do we have so many template to instantiate? Exactly my point: because we couldn't change type definition we could only create new one. How many helper templates gets instantiated to remove const types from the type-list? Should be none. So you are right: it has everything to do with nature of metaprogram evaluation engine, which is FP based one. > In fact, you *can* write metaprograms in an imperative > style, given an appropriate framework designed to interpret > them correctly. It'll be much slower than what we use today. You have any grounds for this statement? > > And Spirit framework would benefit from it the most. > > I doubt that. Parsing in particular has little to gain from > the use of mutable data. I meant from compilation time standpoint. Gennadiy.

2 1

FC++ -- formal review over
by Mat Marcus 02 Mar '04

02 Mar '04

The formal review period for FC++ is over. Thanks to the authors and those who submitted reviews/comments. I will now ask for your patience as I spend some time considering the discussion and preparing my decision. - Mat

1 0

Re: win32.hpp and min/max macros
by Eric Niebler 02 Mar '04

02 Mar '04

John Maddock wrote: > Would you like to make and manage the change? Remove the workarounds from > win32.hpp, and then patch all occurrences of min and max throughout boost? > > John. <recap> We agreed to make boost work in the presence of the min/max macros by wrapping all min/max function identifiers in parens, like (std::min)(a,b); </recap> I have spent some time and made the 800 or so edits throughout boost required to make it play nice with the min/max macros. I'm running regressions now. I have a couple of questions about procedure before I can commit the changes. 1) Is this a good time? I know there's talk about a 1.31.1 release. Will this be done from the 1.31.0 branch or from main? I don't want to destabilize before a release. 2) I can't test with old compilers, which are the ones most likely to have a hard time with this change. Also, I'm not a CVS guru. If all hell breaks loose as a result of this change, is there someone willing to help me back it out? 3) Is there a boost developer style guide where we can document the fact that all calls to min/max functions must be wrapped in parens? 4) This is the sort of thing developers will forget to do even if it's in a style guide. A simple way of ensuring this stays fixed would be to run the regressions with min() and max() #defined to garbage, so that violations are detected and corrected early. Is this possible? Thanks. -- Eric Niebler Boost Consulting www.boost-consulting.com

13 37

RE: [boost] Re: FC++ formal review
by Rozental, Gennadiy 02 Mar '04

02 Mar '04

> > I never question usefulness of function object > (any-morphic). What I > > do seek is an example of lazy list application. > > Then you should say so. "FP has no advantages" is a far cry > from "Lazy lists have no advantages". I actually "cry" "FC++ has no advantages". Take lazy list out of FC++, what we you be left with? Polymorphic function objects? I was agree from the very beginning it should be incorporated. Maybe though not as part of FC++, but boost::function and boost::functional Gennadiy.

1 0

review manager wanted
by Thorsten Ottosen 02 Mar '04

02 Mar '04

Dear all, I'm looking for a review manager for both these two libraries (and it need not be the same person): assignment library (see http://groups.yahoo.com/group/boost/files/assignment/ ) container traits (see http://groups.yahoo.com/group/boost/files/container_traits/ ) Both libraries are fairly small, so they should be fast-track reviews. My personal calendar says that I can handle one review in Marts. There is a good possibility that there could be a 'hole' in the review process during this month where one of these fast-track reviews can be put in. Anyone interested should contact me privately. best regards Thorsten

1 0

como-win32-tools.jam changes broke my builds
by David Abrahams 02 Mar '04

02 Mar '04

The recent changes to como-win32-tools.jam completely broke my ability to use the toolset. Nobody should be calling the "flags" rule on variables indended for user customization. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: boost::ublas and solver
by Michael Stevens 02 Mar '04

02 Mar '04

Dear Loïc, On Tuesday 02 March 2004 00:33, Loïc Joly <loic.actarus.joly(a)wanadoo.fr> wrote: > I was recently trying to convince one of my colleagues that a vector > (mathematical, not stl) and matrix library instead of raw C arrays could > be usefull for his job. An excellent decision! > I naturally turned toward boost::ublas, but then > I had one surprise: One thing I expected to find in such a library was a > collection of solvers (LU, gaussian elimination...), but I found none. The simple answer is in the name 'BLAS'. uBLAS is a library for Basic Linear Algebra. It provides storage for vectors and matrices (dense, packed, and various sparse methods) and basic linear algebra operations. Of course all this is put together in a safe and efficient C++ package! For a more complete answer have a look at http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Linear_Algeb… > Is this because they exist, but I could not find them in the > documentation (btw, I have some trouble to understand the doc, too much > code, not enough english to my taste) ? True. Feel free to contribute documentation. I am using the Boost Wiki to organise new introductory information which can eventually be merged into the official uBLAS documentation. > Is is because there was a good design decision not to include them ? > Is it because this is a very touchy domain and poeple could not agree on > generic solutions ? > Is is just an oversight ? Yes, No and No. There is no end to the number of Linear algebra algorithms. uBLAS provide efficient infrastruture for C++ to solve these problems however. Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://www.sf.net/Bayes++ ___________________________________

2 1

Review Request:serialization
by Robert Ramey 02 Mar '04

02 Mar '04

I've uploaded serialization17.zip to the boost files section. There is also a copy to be found at www.rrsd.com I am requesting a formal review of this submission. I realize there's a queue. I hope that interested parties can find the time to subject this submission to a preliminary review and that at least two of those persons can second this submission. The feedback I've received from recent prior versions of this library lead me to believe that this will occur. Robert Ramey

3 2

FC++ review
by Dave Gomboc 02 Mar '04

02 Mar '04

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)

5 5

FC++: formal review
by Gennadiy Rozental 02 Mar '04

02 Mar '04

Hi, It was quite difficult to review this submission for several reasons: mostly because (from POV) it has virtually no documentation, no structure, no testing and what is most important no clear defined problem domain, where this library provide a solution (here I mean not the function objects facilities, but namely FP part of the submission). What it does have, is a several interesting ideas. In summary it my opinion this submission is unacceptable and my vote is NO. Problem domain ------------------------------------------------------------------------- Unlike my usual review I would like to start with problem domain discussion. Library position itself as a library to do FP in C++. Namely in this order. Kind of like library for crazy Haskell programmer that for whatever reason decided to use C++. Docs (and papers) in details describe how to do things one could do in Haskell using FPC++ analogs. There is even comparison of performance with Haskell compilers: not to worry we almost as fast. For me as a C++ programmer more important is to see the comparison with the same algorithm implemented with other usual C++ techniques. I did one myself. I took an example used by authors for performance testing and modified it like this: .... here is what is already in test //////////////////////////////////////////////// inline bool is_prime( int i ) { for( int c = 2; c <= i/2; ++c ) { if( i % c == 0 ) return false; } return true; } inline int nth_prime( int N ) { int i = 1; while( N > 0 ) { i++; if( is_prime( i ) ) N--; } return i; } int main() { acc_timer timer; // acc_timer is my timer class based on gettimeoftheday int NUM; cout << "Num primes = "; cin >> NUM; timer.start(); list<int> l = primes(NUM); int i = at( l, NUM-1 ); timer.stop(); cout << i << endl << "took " << timer.elapsed() << " sec" << endl; timer.start(); i = nth_prime( NUM ); timer.stop(); cout << i << endl << "took " << timer.elapsed() << " sec" << endl; } The algorithm I am using similar to the one use by original code. The only difference is that I am not using FC++ abstraction. I was using gcc 3.3.1 under cygwin on my Athlon 2000+ PC. I was using following command for compilation: g++ -O4 -I [list of include directories] tw_primes.cpp Here is the result of several runs: Num primes = 500 3571 took 4.825 sec 3571 took 0.015 sec Num primes = 750 5693 took 11.703 sec 5693 took 0.036 sec In average FC++ solution is 320 times slower. For any practical usage price of an abstraction should not exceed 10-20%. With price as high as FC++ currently shows I wouldn't even start to think in this direction. In general from my experience usage of lazy evaluation quite limited (in FP sense - I do not mean binding the arguments, which is widespread). It may be used sometimes, but I know many more other neat tricks that are more or as useful. IMO authors need to justify need in lazy list as a generic reusable components in C++ (namely in C++ not for FP which says nothing to me), but for now I do not see a place for them. Some papers does try to justify need for FP to implement common design patters in C++. But actually they only shows need for use of polymorphic functors nothing more. Design ------------------------------------------------------------------------- I with almost everything authors says about need of polymorphic functors and the way they design support for result type deduction. But I believe it should be boost-wide solution. With support in both boost::function, boost::bind and boost::lambda. I don't think we need indirect functoids (with their virtual functions and smart_pointers inside). boost::function should be made result_of aware instead. I couldn't comment on design of lazy lists since it does not described in docs. But I still not convinced that there exist a problem to justify need for this construct. Lambda facilities design is also offsite and it's difficult to comment on it by itself and on comparison with boost::lambda. In my personal opinion there should not be two different facilities dedicated to the same cause within boost. If you have any issues with boost::lambda lets resolve them. In other case it would only source of confusion to the users and make them both less useful. Monads are not covered and not commented accordingly. Explicit built-in currying (I prefer term binding) looks like convenient idea and I would vote to include this info boost::function Implicit built-in currying on the other hand like more like a source of confusion than convenience and in my opinion should not be included. It not only may confuse inexperienced user, but also may cause a conflict If I have function polymorphic not only in regards to the type of the arguments but also in regards to their number. I do not understand need for separate notion of thunks. Why couldn't we just bind all function arguments using usual means? Library supply the collection of predefined function object. While I can blindly accept polymorphic counterparts to the STL functional ones, the rest should be documented and discussed one by one (the fact they belong to mythical "prelude" says nothing to me). Also from sources it looks like many of them operate on lazy lists. Why couldn't we have them as a member functions? They are not generic to be used for different kinds of lists (like STL list) and what is an advantage to length ( ll ) vs. ll.length(). Would I need to pass this method anywhere (rare case IMO) I could use an adaptor. Infix syntax: I do not think this feature useful enough to justify weird syntax. Most probably it wouldn't be use for anything other then several functors like plus, minus. Documentation ------------------------------------------------------------------------- There two major problems I have with docs: first they are very scarce on design of the component described and second they are written for Haskell programmer who is learning C++. I believe that at least 90% of C++ practitioners never heard about Haskell. Accordingly it should not be mention in docs AT ALL. The should not be ANY references to Haskell syntax, which instead of clarifying things make it worse and left me with feeling that I did not get something. There should be a short introduction to what is a functional programming paradigm. Comparison with existent C++ paradigms, advantages and disadvantages. I don't say it should be extensive multipage work, but just an introduction for C++ programmer not familiar with FP. There should be reference documentation for any functor supplied by the library. I am not sure there is a need for old (pre boost) references in docs. It absolutely unnecessary for new users. Why existent users may use some kind of transition guide in FC++ website. The rest of docs looks in most part as a "simple overview", while I expect to see a real full documentation. Implementation ------------------------------------------------------------------------- 0. It would be much easier if you would follow recommended boost directory structure 1. BOOST_FCPP_DEFER_DEFINITIONS This does not look like a good solution. What exactly did you try to achieve? 2. definition.cpp What is this? Does it gets compiled by any compiler? 3. All implementations needs to be rewritten using Boost PP to be extendable to more then 3 arguments. 4. Why fullN does not inherit from it's parameter, but keep it as a member instead? 5 What is konst vs. const? 6. When you will eliminate implicit currying implementation became more simple 7. binderNandK...ofM facility does not look extendable. Did you look how boost::bind is implemented? 8. There are still a lot of identifiers that does not follow recommended boost naming policy 9. Why infix syntax implementation is mixed with some library supplied functors? Testing/Examples ------------------------------------------------------------------------- There is a lot of staff in fcpp_clients directory. Since there is no test/examples separation and no Jamfiles I couldn't comment in details how it looks. Regards, Gennadiy.

7 9