Re: [boost] py_cpp

From: Mark D Rintoul (rintoul_at_[hidden])
Date: 2000-10-17 16:01:42

Paul Baxter wrote:
> 
> My reasoning for it being inappropriate is that it seeks to solve a
> specific interfacing difficulty with one language rather than a more
> generalised issue of say interfacing with ANY or a subset of other
> languages.
> 
> I am not arguing whether such a generalised approach is feasible, but I
> would see Boost's content as more generic.
> 

        Hear, hear!  I have been "lurking" on this mailing list for a
considerable time now, reading most of the postings, using much of the
code, but not saying much since there always seemed to be someone out
there who put forward my position, and usually better than I could. 
Much of the more generic boost code, such as compose, functional, 
type_traits, and utility has been a godsend in my work.  I have muddled
about with my own versions of such things, but there have always been
little holes in my personal libraries since I didn't have much time to
devote to getting them perfect, and they weren't subject to the peer
review that the boost submissions are subjected to.  

        I really feel that boost's strength lies in fixing the minor
design errors that inevitably crept into the standard libraries
development
such as the problem with binders and double references.  I would
anticipate
that some form of these fixes would make their way into the updated
version
of the standard.

> The standard library, for instance, puts forward the general container
> and iterator concepts before providing a specialised set of containers
> etc.
> 
> In much the same way I would hope that Boost members would discuss what
> concepts, patterns of usage etc are required before embarking on a
> specific inter-language library even if it is in the context of a python
> interface.
> 
> The current discussions regarding callbacks might well be one general
> concept that becomes a piece in such a puzzle.
> 

        Agreed.  Let me just add that I'm one of the folks who uses
the STL extensively everywhere in my code.  Not just for the obvious
places, but pretty much to get rid of for (and while) loops and their
iterators everywhere.  It's not a coding style for everyone, but
once you get used to a screen full of for_each's and transform's, it
(eventually!) becomes fairly natural to read.  And besides, if they
didn't want me to use them, they shouldn't have put them in the
language!
I also understand the arguments against such coding style and have
no problems with those opinions.

        I have found that you can emulate any standard looping construct
with the STL, if it is "filled out" just a little.  There are two
fundamental things that are missing that have a natural fit within the
STL (and in fact, seem to break the symmetry of things by not being
there).
The first is the lack of a two operator "for_each" that works something
like

        while (first1 != last1) f(*first1++,*first2++)

and this is even mentioned on p. 532 of Stroustrup.  It seems a little
unfair that transform gets a two arg form and for_each doesn't.

        The second thing that is missing is an "_if" version of for_each
and transform that would work something like

        while (first != last){ if (pred(*first)) f(*first); ++first;}

for the single argument for_each_if.  

        These not only round out the ability to make generic loops, but
adding the second arg version of for_each would not break any current
code, and the _if versions of each would blend in very nicely with the
_if versions of all of the other functions.

        I'm not trying to be the sort to say "I think we should add these
things to the STL because I use them", but this came about both through
real apps and an attempt to figure out why certain types of
constructions
were very hard to do within the current STL framework.

> Note that I understand the need for specific language implementations
> first before generalisations can occur, but it is those generalised
> concepts that I think should provide the foundations of any such library
> in Boost.
> 
> Throughout this, I hope it is clear that I am very impressed with py_cpp
> and do wish to devote some time to using it in the near future.
> 
> I am impressed with the effort Dave, Ullrich and others have put into
> the library but do not feel comfortable with its inclusion in Boost.

        Of course, the comments on code quality go without saying.  I
love the generic graph library, and think it is one of the best
public domain packages of its kind.  But it would be nice to try to
avoid becoming an ftp site for public code, no matter how strictly 
reviewed and how controlled the quality is.

-- 
------------------
Mark D. (Danny) Rintoul, Dept. 9235
Computational Biology & Materials Technology
Sandia National Laboratories
Phone: [phone], Fax: [phone]
email: rintoul_at_[hidden]
------------------