Programming languages can be extended in two ways: by extending the language
syntax, and by adding new library modules. As a strong advocate of
object-oriented design, I favor the latter over the former. Rather than add
yet-more-complexity to the base language, we should strongly consider how
new features can be added via standard classes.

A library-based approach eases both learning and implementation.

In terms of learning: If concurrency is implemented via standard classes, a
programmer who does not use concurrency does not need to learn that library.
This approach encapsulates complexity, by allowing programmers to learn what
they need to know when they need to know it.

In terms of implementation: New language syntax often breaks compilers;
using a library-based approach allows vendors to stabilize the compiler,
providing greater reliability for both library and user code. Distinct
library sets support incremental movement toward a standard; a vendor could,
for example, make sure their concurrency classes were complete and reliable
before implementing classes for (say) matrices.

Certainly there will be some additions in the core language, perhaps in
support of new idioms and some compatibility with C99. In the end, however,
I believe that C++ is best served, whenever possible, by library-based
extensions that provide concise, modular, encapsulated solutions. While C++
should not emulate Java (too many libraries, too many target audiences),
major language enhancements can be made effectively through new standard
classes.

--
Scott Robert Ladd
Master of Complexity
Destroyer of Order and Chaos
http://www.coyotegulch.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Scott Robert Ladd wrote in message ...

>Programming languages can be extended in two ways: by extending the
language
>syntax, and by adding new library modules. As a strong advocate of
>object-oriented design, I favor the latter over the former. Rather than add
>yet-more-complexity to the base language, we should strongly consider how
>new features can be added via standard classes.


That is widely cited, but rarely supported by arguments. IMHO from learning
perspective most library issues are nothing less complex, and when equal you
still have to remember atl least one plus element: what header to include.
But in a more typical situation you must learn the whole surrounding
package, or get burned.

Core additions really _can_ be made so to introduce new, unpredicted
behavior, or confuse compilers in new ways, but that does not apply to all
of the possible additions.

Suppose you start designing C++, and have an almost clear table of
operators.

You add operator ==. It really adds to complexity, introducing its
precedence and associativity rules. Then you add operators !=, <, <=, >, >=.
Those IMHO introduce no new complexity. You just refer to the rules already
being there, and enjoy the features.
Suppose we wanted a minimalist set of operators and had only !, ==, <, ||
and &&. (or ^^ instead of && and ||, let's forget the shortcut evaluation
for now ;-).
With cleverly formed instructions we could write all the expressions we can
with the full set. The question is did we really create a less complex
language?  I'm sure we created, in practice, a much more complex one
instead, and an ugly one too with a need to a plenty of hand-made tools to
cover the holes. As surely most programmers will feel miserably, and
introduce macros for all the missing operators and start using those.
Everyone with his own preferred name. Others will use inline functions. or
other similar stuff. Some macros will meet function names, and you just wait
until the whole chaos fells down.

C++ is quite a rich language at the core, so it is not at all hard to find
an existing keyword to stick similarly working new one. And if that covered
an area everyone encounters sooner or later, and must look for inferior
hand-made solution, or one made by others that's supposed to work, just
looks like black magic, we had a big net gain.

Complexity is not measured by a mere count of keywords.
I've seen quite a plenty of proposals and feature reqs here, needing core
support. Most of those probably much more important than any kind of library
addition.   As I can write, or download a library doing some task, but I
can't obtain a new compiler.

>A library-based approach eases both learning and implementation.


IMHO library-based approaches has quite another big advantage: it needs no
preliminary decision, and premature changes to anything. Just look out what
popular libraries are there, those programmers actually use, and find
useful. Then when you see one widespread, and more importantly, stable
enough, make that one standard.   It also has the side-effect of reducing
committee work, no fights over individual class designs and member
functions, the stuff is ready.

>In terms of learning: If concurrency is implemented via standard classes, a
>programmer who does not use concurrency does not need to learn that
library.
>This approach encapsulates complexity, by allowing programmers to learn
what
>they need to know when they need to know it.


Well, that is another good example, which I consider a counter-example. I
could see a few easy core additions to support threads, namely the concept
of "logical memory barrier" (LMB) -- which does nothing really tough stuff,
just inhibit optimisation, moving code across that location; give some
points that are supposed to have an implicit LMB (star and end of access to
a volatile object is a good candidate). Then, the concept of "externally
visible object" (EVO), that would grasp what is the state an external
observer, most importantly code executing in other threads can see. (What
could include all objects, minus (local objects minus local objects with
their address taken)).  The compiler shall generate code in a way that at a
LMB the state of EVOs reflect everything happened to that point, and
everything that would happen after, should happen after.
And as a third thing a new function-like keyword membar(arg); with arg
coming from locesd set of none/red/write/read_write. Supposed to bring an
implicit LMB, and emit a platform-specific memory barrier instruction for
the respective mode (if needed, certainly).
Being that function-like does not fit to be a regular function in a library,
as it has that special LMB side-effect. [same issue as why a null pointer
constant should be std::null or something; if it needs special handling by
core let's not pretend it is library!]

[note: most implementations with threads support already work along those
lines, just not saying so. All to be done is specifying the existing
behavior! So we could rely on really standard behavior, not on "we observe
that making this thing volatile, or inserting an otherwise unneeded lock()
here makes the code behave as we wanted".]

I believe having that minimal support every MT issue can be really solved in
libraries. And those libraries are what should not be going into the
standard. For the single reason you cannot pick one library, that would work
well on significant platforms. People using just WIN32 want a library on
WIN32 features, no way missing the unique features. Other people on posix
platforms will pick the posix library. Those needing portability on both
will use some handy mix, restrainig to common features. Then we also have
the solaris api, and several others. you just can't make a really useful
common base, especially one more attractive than using the original api, or
the own wrappers, everyone probably written long ago.

>Certainly there will be some additions in the core language, perhaps in
>support of new idioms and some compatibility with C99. In the end, however,
>I believe that C++ is best served, whenever possible, by library-based
>extensions that provide concise, modular, encapsulated solutions. While C++
>should not emulate Java (too many libraries, too many target audiences),
>major language enhancements can be made effectively through new standard
>classes.


IMHO it's not a coincidence the content of standard library is what it is
now. commonly used containers, algorithms. That should belong there. Maybe
we'll get a simplified, nontemplate string, or a few variants optimised for
different tasks. Some new containers that are not represented today,
hashmaps, more sorts, algorythm binders. All kinds of numbers.
Cryptography-related functions (patent issues are void for the most popular
ones, so all we need is ecent implementation :).  New cool templates we see
under development.  But for the very reason you just wrote I do not expect
highly platform-specific stuff, like GUI support or threading library.

Paul


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]