From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7f2ce8bda9cae4ab X-Google-Attributes: gid103376,public Path: controlnews3.google.com!news1.google.com!newshub.sdsu.edu!newshosting.com!nx01.iad01.newshosting.com!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.icl.net!proxad.net!freenix!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: "Alexander E. Kopilovich" Newsgroups: comp.lang.ada Subject: Re: "Must instantiate controlled types at library level." Why? Date: Wed, 19 May 2004 05:20:55 +0400 (MSD) Organization: Cuivre, Argent, Or Message-ID: References: NNTP-Posting-Host: lovelace.ada-france.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: melchior.cuivre.fr.eu.org 1084930077 7927 212.85.156.195 (19 May 2004 01:27:57 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Wed, 19 May 2004 01:27:57 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: In-Reply-To: ; from "Dmitry A. Kazakov" at Tue, 18 May 2004 09:48:41 +0200 X-Mailer: Mail/@ [v2.44 MSDOS] X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Gateway to the comp.lang.ada Usenet newsgroup" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Xref: controlnews3.google.com comp.lang.ada:677 Date: 2004-05-19T05:20:55+04:00 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