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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f51e93dacd9c7fca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-09-30 10:12:51 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeed.berkeley.edu!news-hog.berkeley.edu!ucberkeley!newshub.sdsu.edu!west.cox.net!cox.net!newsfeed1.earthlink.net!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!harp.news.atl.earthlink.net!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: status of Ada STL? Date: Mon, 30 Sep 2002 13:12:09 -0400 Organization: MindSpring Enterprises Message-ID: References: <3d0f0c40_1@news.tm.net.my> <3D95E5F7.CE1669E9@adaworks.com> NNTP-Posting-Host: d1.56.b2.51 X-Server-Date: 30 Sep 2002 17:12:50 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Xref: archiver1.google.com comp.lang.ada:29431 Date: 2002-09-30T17:12:50+00:00 List-Id: I'm curious about what you're looking for archtecturally? Some sort of breakdown of library domains? (e.g., "Containers", "Mathematics", "OS Services", etc.) A breakdown of implementation concepts? (Dynamic vs Static, Generic vs Object Oriented, etc.) Or just a breakdown of desired functionality? ("A list container will have the following types, operations, etc.") In my mind, I could see adopting an existing container library and not trying to get it into the standard. Just a library that is a reference implementation and is deemed to be suitable for most practical purposes. Something the vendors would package with their compilers on an "As Is" basis with the only promise being that most/all implementations of Ada come with this library and the only guarantee is the package spec - behavior may vary some. This isn't far afield from what other languages have done in the past and continue to do - maybe it eventually makes it into a standard, but who cares so long as it exists in all implementations and the behavior is at least mostly the same everywhere. In a perfect world, I'd like to see a lot more than just containers supported since anything Ada does to give the developer leverage makes Ada more attractive. Why *not* have a big math library and make Ada more attractive for the numeric types of projects? Why *not* have a communications suite that provided network interfaces and made Ada more attractive to distributed computing projects? Why *not* have a business library that provided facilities for common business computations and make Ada more attractive to data processing applications? I've known people who have been big fans of Ada but have taken their projects to other languages with the story always being the same: "I really like Ada, but I can get my job done so much faster by utilizing what comes with " Ada can provide the same leverage and might even do it better, but not if it waits until a perfect answer is found. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jast.mil/ Send Replies To: m c o n d i c @ a c m . o r g "I'd trade it all for just a little more" -- Charles Montgomery Burns, [4F10] ====================================================================== Richard Riehle wrote in message news:3D95E5F7.CE1669E9@adaworks.com... > > I seem to recall that George Bernard Shaw wrote, "If you layed all the > economists in the world end-to-end, you will wouldn't reach a conclusion." > > I think the same is true if you lay all the programmers end-to-end, > especially > when trying to get agreement on something as subject to variation of > intepretation as standard libraries. > > Perhaps, before commiting anything to code, in any language, we should be > discussing the underlying architecture for this kind of standard library. > Yes, > I realize that language structure is an important consideration, and that > linguistic continuity is largely influenced by programming language > structure. > However, there may be enough architectural issues to permit discussion of > this > at a slightly higher level of abstraction. > > This suggestion is not meant to deprecate the work that has already been > represented in source code. In fact, that work is an important contribution > > to raising the discussion to the next higher level of abstraction. > > Richard Riehle >