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 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-11 19:10:43 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newshub.sdsu.edu!elnk-nf2-pas!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!newsread2.news.atl.earthlink.net.POSTED!not-for-mail Message-ID: <3F88B81F.8000403@noplace.com> From: Marin David Condic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (OEM-HPQ-PRS1C03) 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> <3F86FE09.3050302@comcast.net> <3F8816EB.1010009@noplace.com> <3F88A577.5000803@noplace.com> <6Z1ib.15647$0I6.14413@nwrdny03.gnilink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 12 Oct 2003 02:10:42 GMT NNTP-Posting-Host: 209.165.25.238 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.news.atl.earthlink.net 1065924642 209.165.25.238 (Sat, 11 Oct 2003 22:10:42 EDT) NNTP-Posting-Date: Sat, 11 Oct 2003 22:10:42 EDT Organization: EarthLink Inc. -- http://www.EarthLink.net Xref: archiver1.google.com comp.lang.ada:695 Date: 2003-10-12T02:10:42+00:00 List-Id: Stephane Richard wrote: > > > *** Would we need to stipulate that all you do need to do is rename > it to make it part of the ada hiearchy? as in make sure you just > globally rename it and it still works exactly the same? or do you > not see a situation where this might be conflicting with anything > already existing into ada? Basically treat CAL as Ada when naming > libraries and at that point possibly making a copy of the Ada > hierarchy into the CAL database to make sure they can't be named the > same? If there's no imminent problems, than that idea is fine with > me :-). let's see what others think. > Let's get that cart *behind* the horse. :-) Suppose you had a package spec called "CAL.Containers.Lists" and it provided a simple, basic, run-of-the-mill linked list data structure. It gets packaged and shipped with every Ada compiler and might be periodically updated to fix bugs or add a few new features. No problem. Its not in the ARM, so nobody is going to get their panties in a bunch because the changes are "non-standard". Ultimately, you're no worse off than if you are hooking up to the Win32api - Micro$oft issues a new release and something changed and you've got to potentially go fix your code. No big deal - its done every day. Ten years from now when the ARM is getting revised again, ACT, Aonix, RR, et alia, all sit around in the smoke-filled room of the ARG headquarters and say, "We think that CAL.Containers.Lists needs to be incorporated into the standard and become "Ada.Containers.Lists"..." What's the problem? The ARM simply copies the spec, changes the names and adds a whole bunch of words that says "Ada.Containers.Lists must behave in this manner..." How you get it there is an implementation detail. Since the vendors already have CAL, they could copy & rename the source as needed. They could use a renames if they wanted to. It doesn't matter. In the mean time, the CAL library still contains a CAL.Containers.Lists and the editors of CAL have to decide what to do about it. They could declare it to be a feature that is superceded by the ARM and discontinue any modifications to it - basically pointing at its counterpart and advising you to use that as its successor for all new development. They could continue to modify and extend it to see if some new features become desirable & perhaps impact the next ARM. They could delete it and tell their users to either go with an earlier version of the library or convert to the ARM version. Its an incredibly TBD issue and it really doesn't matter today what direction it goes down. The point is that A Solution Does Exist, so don't try to figure it out *today*. > > > *** Yes I believe that's a good way to go about it. Licenses will be > licenses when they are licenses :-) . > Ultimately, if the vendors are distributing it, they will have all sorts of interest in exactly what license is used. They may all want the GMGPL. They may want it all in the public domain. They may want it with some kinds of restrictions so it can serve as a revenue source. (*Someone* has to pay to build it & maintain it. You'd better figure out how that's going to work because it will affect how you structure the deal & the license.) So get an understanding that says "Yeah, we're hip to this and want to do it..." Let them argue about what sort of license to put it under once they decide they want it. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m c o n d i c @ a c m . o r g "All reformers, however strict their social conscience, live in houses just as big as they can pay for." --Logan Pearsall Smith ======================================================================