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,7ee10ec601726fbf X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-30 10:18:07 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!psinet-eu-nl!psiuk-p4!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: why not Date: Tue, 30 Oct 2001 12:41:22 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9rmoo2$rde$1@nh.pace.co.uk> References: <3BC5D730.DA950CC7@boeing.com> <9q4pa7$1ad$1@nh.pace.co.uk> <3BC6ACC8.23EF21BC@free.fr> <3BC71F54.1FFE78FA@boeing.com> <1KGx7.26476$ev2.35117@www.newsranger.com> <3BC7AD82.2A0CCCD4@acm.org> <9qhiqr$af0$1@nh.pace.co.uk> <1nDC7.180$6S7.92255364@newssvr11.news.prodigy.com> <9rjsak$bp3$1@nh.pace.co.uk> <9rmhb9$o1b$1@nh.pace.co.uk> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1004463682 28078 136.170.200.133 (30 Oct 2001 17:41:22 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 30 Oct 2001 17:41:22 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:15430 Date: 2001-10-30T17:41:22+00:00 List-Id: I would shed about as many tears over it making its way into an annex as I did over Ada.Strings... making it into an annex. However, I imagine that process would be a bit cumbersome and less likely to happen. I can't begrudge the vendors objecting to something that is poorly defined and/or difficult to verify being in the standard since this could cause them lots of trouble getting their compilers validated. That's why I'd accept something as an informal, de-facto standard rather than an ARM annex. IOW, if there is some pile of source that they can simply adopt and it is what it is with no guarantees about behavior, it makes a start at something that might eventually be formally standardized. If you look at something like C, you notice how there were originally no "standard" libraries of useful functions for things like strings, etc. Its just that most implementations shipped with these function libraries in some form - often not entirely compatible. Yet there they were. People used them. Eventually, they got to be such common fixtures that ANSI C ended up including them. Granted, C has a much more "sloppy" history with respect to standards and verification, but it *did* enable some creative inovations to work their way into the language. I don't see anything wrong with one or more vendors providing something equivalent in Ada and, if it gains some acceptance & standardization, eventually getting it into an annex. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Pascal Obry" wrote in message news:ud735kqak.fsf@wanadoo.fr... > > Well this was maybe because Ada83 had no annexes. Now that we have annexes in > Ada95 I think this is quite different. Just put this stuff into an annexes. > > I really think that this kind of libraries should be a part of Ada95. If some > peoples object about verifiability then I think that this annexes could be > named Unchecked_And_Very_Dangerous_Library :) > > Most part of the application domain where Ada is designed to be used just do > not ask for verifiabilily. >