Re: [boost] py_cpp

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-10-18 13:02:57

I've now got some time to respond to some of the questions about
appropriateness for boost...

----- Original Message -----
From: "Moore, Paul" <paul.moore_at_[hidden]>

> From: David Abrahams [mailto:abrahams_at_[hidden]]
> > For the record, I have never had a clear idea of whether py_cpp
> > is appropriate for Boost - as the first inter-language library,
> > it certainly goes into uncharted territory for us. I asked the
> > question many months ago when I posted the first versions of
> > what I had done, but the group was silent on the topic.
>
> I recall the posting. I don't think I (personally) understood the
> implications of what you were saying at the time. Sorry. I see your point
> that inter-language libraries are a valuable resource, and I take the
point
> that just because this is the first does not mean it is inappropriate.
>
> FWIW, my view is that the "official" Boost libraries should be an
extension
> of the C++ standard library, in principle. That is, platform-independent
> code which provides useful functionality for people coding applications in
> C++.

Well, py_cpp certainly fits that bill. Python is probably more portable, by
any reasonable measure, than C++ itself.

> In a similar manner to the C++ standard libraries, I see value in
developing
> a standardised interface for certain highly generic OS-dependent
facilities
> (like the iostreams facility). This should be handled with care and
> restraint, so as not to rely on features which may not be available on all
> platforms (I know some platforms don't even have a concept of IO - there
has
> to be a balance here). An example of this is the thread stuff. While a
> generic threading library would be nice, we have to focus on the
"standard"
> and "cross-platform" aspects (and the consequent "minimal" aspect) -
> otherwise we end up just picking one OS's approach and porting it to those
> platforms we care about.

IMO we have an opportunity to do things in boost that we can't do easily in
the standard. When considering a new library for the standard, these two
obstacles (among others) arise:
1. What about platforms that don't support that feature? Can we really
require the library to contain that component?
2. Where's the proof-of-concept?

They feed into each other in a viscious cycle. Nobody bothers to make an
implementation that could be considered for the standard because they know
we wouldn't be able to make a C++ compiler for some currently supported
platforms. These problems are part of the reason we don't currently have
thread support. Boost gives us the opportunity to deal with #2 until the
language lawyers figure out how to appropriately broaden the scope of the
standard.

> In this context, inter-language libraries are fraught with issues. We end
up
> inadvertantly taking sides in language wars ("why does Boost support
Python,
> but not Perl/TCL/Ruby/Lua/...?"). We are also tied into other software's
> versioning issues (does py_cpp interface to Python 1.5, 1.6 or 2.0?).

I agree with another poster that py_cpp can begin to provide a generic
framework for interfacing with other dynamic languages. I also believe that
inter-language interface is going to be one of those areas into which it
will be important to broaden the scope of C++, eventually.

> > One of the reasons I thought it might be a good thing to
> > include at boost is that Python's standard library still covers
> > a vast number of useful areas that std + boost do not.
>
> I'm not sure what you are implying in this. Can I write a sockets program
in
> C++ with py_cpp and Python? I assume that the resulting program would rely
> on Python, and hence would not compile into a single distributable EXE?
None
> of this is bad in itself, but it reflects back to the "is this appropriate
> territory" question again.

We haven't dealt with packaging issues with any other libraries at boost;
I'm not sure why it should be a more important issue in this case.  (?)

> > I'm not sure that a library's review should be considered
> > premature just because there is lots of room for
> > expansion/improvement. In this case, one of the points of the
> > review would be to get a feeling for which of the new features
> > is most desired by potential users.
>
> Agreed. I strongly believe that we should get things into the official
Boost
> distribution "as soon as they are ready". Stability has to be a part of
> that, but also relevant are portability to as many compilers/OSes as
> possible, usefulness, completeness of documentation, ...
>
> Rejecting one library because it is likely to change, when we accept
another
> which doesn't run on half the C++ compilers out there, and another which
is
> barely documented, is unreasonable. Once a library is accepted, it will
get
> more users, and so there will inevitably be pressure to change things.
This
> is not a bad thing.
>
> Also, review (and subsequent acceptance) imply a commitment to developing
> and improving the library. Having a large number of libraries permanently
> "under construction" but never complete is more damaging to Boost's
> credibility than having released libraries undergo (controlled) change
would
> be.

All of these sound right to me.

> It's about the change from development to support. Support doesn't mean
> stagnation, but it does mean a focus on not breaking compatibility for
> existing users.

/What/ is about the change from development to support?

> > Is the concern that rapid improvements to a single library
> > might cost boost some credibility?
>
> It's an issue, but no more so than the others I mentioned. Even the
standard
> library changed between versions of the draft. The key thing has to be a
> visible stable goal, and progress towards it. OTOH, if a library is
clearly
> "alpha quality", then it should wait a while before acceptance.

Agreed.

> > I'm not offended in the least, and am happy to leave that
> > decision up to the group at large. That said, I think it is
> > important that if we decide not to accept py_cpp, that we
> > understand the criteria for making that decision, so we can
> > make them part of boost policy. So far, the remarks I've heard
> > do not clearly state what it is that would cause py_cpp to be
> > deemed appropriate or inappropriate for boost.
>
> Agreed. Clarifying this issue is very important. In my view, it affects
not
> just py_cpp, but also the threading discussions and probably other areas
as
> well (there was some talk of GUI libraries a long while ago).
>
> As a general principle, I would argue that the basic benchmark would be
"can
> we imagine this library being accepted into a future version of the
> standard?" On that test, I'd say that py_cpp would fail (and threads is
> borderline). But this needs clarifying and tightening up before it is a
> reasonable guide. (Assuming that the group agrees with me).

It really depends whether you think that the general scope of the C++
standard will be limited for all time to generalized computational jobs and
basic i/o. I believe that for C++ to survive and thrive, it will need to
have a vastly expanded library, that begins to cover the same kind of
territory as Java's or Python's library (see
http://www.pythonlabs.com/pub/www.python.org/doc/current/modindex.html). Why
do people decide to build their GUIs in web browsers with
HTML/Java/JavaScript instead of C++ these days? There are lots of reasons,
but the fact that there's no standard, portable C++ GUI is one of them.

Just to prove that inter-language binding isn't too far afield, I'd like to
point out that there is already a subgroup of the C++ committee working on a
standardized SQL binding. Herb Sutter is leading the group.

-Dave