Re: "Must instantiate controlled types at library level." Why?

["Alexander E. Kopilovich" <aek@VB1162.spb.edu>]

Dmitry A. Kazakov wrote:

> >> Clearly it is
> >> desirable to have a minimal set of first-class things providing a
> >> richest possible set of second-class ones with minimal efforts.
> >
> >This is a language-oriented view, not an application-oriented view, and it
> >isn't (and can't be) shared by vast majority of C/C++ users.
>
> Everything depends on what is language and what is application. A
> component library is an application that directly use the language. A
> business application might view both the core language and the
> container library as the language it deals with.

Typical mathematical (algebraic or topological) relativity -
 (base, extension) -> larger object  ( <- sub-object )

> This ladder might be endless,

Again, a resolvent corresponds to that in some of those mathematical domains

> but at any height the principle holds.

Well, principle may be held locally - at each step - but in perspective of
several consequtive steps, the situation easily may become quite complex,
so that it can't be described adequately by same principle. Also, even locally
the principle may be held in some sense, but not so straightforward - for
example, what mean that some set of first-class things *provides* a richest
possible set of second-class one with *minimal* *efforts*? We have there 3
notions, which can be treated non-trivially. As a good example of possible
non-triviality I'd propose 2-categories, where even the notion of equality
gets uncommon (but perfectly rigorous) meaning. which is a generalization of
common notion of equality in non-trivial way.

> But to have a library you need the language first.

You may be surprised, but I don't think so. More precisely, I don't think 
that we must have a language in advance or restrict ourselves to a single
language. A library is not necessary an extension of a particular language -
this is just a viewpoint and an approach. Another viewpoint and another
approach is to build a library as a programming implementation of some
theory. To have a library with the latter viewpoint/approach we need not
the language first. We even may postpone decision about the languages that
we will use (yes, several different languages - why not?) for various parts
of our library until the design of the library will reach some level of
refinement. What we need first with this approach is solid theoretical ground
and clear and consistent requirements for implementation.

> And as the story of
> container libraries shows, the languages (both C++ and Ada) seem to be
> insufficient for this job.

The story of container libraries shows once again already known fact: Ada's
weakness for *general-purpose* libraries. I think that many Ada.* packages
suffer one way or another from this weakness.

I guess that from viewpoint of general-purpose libraries, Ada's packages are
somehow overloaded with various features and restrictions. What is good for
specific-purpose library may be not so good for general-purpose one. I'm not
calling here for reconsidering of the notion of package (and not because it
is impossible, but simply because current packages are good enough for
specific-purpose libraries), but I think that there can be another (i.e.,
additional) construct, more flexible and less concerned about effectiveness
(and even about readability - one may notice that general-purpose libraries
have much more chances to be supplied with additional materials then most of
specific-purpose libraries).




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia