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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,88ed72d98e6b3457 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-10 11:44:58 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newshub.sdsu.edu!elnk-nf2-pas!newsfeed.earthlink.net!wn14feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!rwcrnsc51.ops.asp.att.net.POSTED!not-for-mail Message-ID: <3F86FE09.3050302@comcast.net> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Standard Library Interest? References: <3F7F760E.2020901@comcast.net> <3F8035B0.7080902@noplace.com> <3F816A35.4030108@noplace.com> <3F81FBEC.9010103@noplace.com> <6Ingb.30667$541.13861@nwrdny02.gnilink.net> <3F82B4A4.5060301@noplace.com> <3F82F527.3020101@noplace.com> <3F846B5E.9080502@comcast.net> <3F855460.6020804@noplace.com> <3F86211B.103@comcast.net> <3F8640CA.6090306@noplace.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.34.139.183 X-Complaints-To: abuse@comcast.net X-Trace: rwcrnsc51.ops.asp.att.net 1065811497 24.34.139.183 (Fri, 10 Oct 2003 18:44:57 GMT) NNTP-Posting-Date: Fri, 10 Oct 2003 18:44:57 GMT Organization: Comcast Online Date: Fri, 10 Oct 2003 18:44:57 GMT Xref: archiver1.google.com comp.lang.ada:640 Date: 2003-10-10T18:44:57+00:00 List-Id: Marin David Condic wrote: > > You meant Ada.Containers, right? Of course, if it is necessary, one > > could be a renaming of the other. > > > Nope. Nothing under Ada unless the ARM explicitly makes it legal to > extend things under the root package Ada. There are times I'd have liked > to extend things under the root package Ada - except its illegal to do > that. If you've got an Ada.Containers, you'd like some end user to a) > have source for Ada.Containers and b) be able to tweak or adjust it or > extend it with whatever good ideas he may have. (Like maybe > Ada.Containers.Realtime? Or Ada.Containers.Bounded?) If this is > difficult to allow, then start another tree that is totally independent > and under which it *is* possible to extend. That is why I mentioned renaming. But if there is an Ada.Containers, then I think it should be used in preference to CAL.Containers. By the way, the ARM A.2(4) says that: "In the standard mode, it is illegal to compile a child of package Ada." But don't take that to mean what it doesn't say. The AARM adds a reason, a ramification, and an Implementation Note: Reason: The intention is that mentioning, say, Ada.Text_IO in a with_clause is guaranteed (at least in the standard mode) to refer to the standard version of Ada.Text_IO. The user can compile a root library unit Text_IO that has no relation to the standard version of Text_IO. Ramification: Note that Ada can have non-language-defined grandchildren, assuming the implementation allows it. Also, packages System and Interfaces can have children, assuming the implementation allows it. Implementation Note: An implementation will typically support a nonstandard mode in which compiling the language defined library units is allowed. Whether or not this mode is made available to users is up to the implementer. The reason and the ramification are very important here. In standard mode, you are guaranteed that Ada.Text_IO is the standard Ada.Text_IO. But if there is a container library in Ada, adding children, especially children that extend the original package is allowed. (Incidently, the real, intended, rule is that vendors should have a special mode for recompiling the standard libraries, and replacing library units and their children defined in the RM should not otherwise be possible.) -- Robert I. Eachus "Quality is the Buddha. Quality is scientific reality. Quality is the goal of Art. It remains to work these concepts into a practical, down-to-earth context, and for this there is nothing more practical or down-to-earth than what I have been talking about all along...the repair of an old motorcycle." -- from Zen and the Art of Motorcycle Maintenance by Robert Pirsig