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,ac39a12d5faf5b14 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-04-20 03:36:20 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!psinet-eu-nl!psiuk-p4!uknet!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: Grace and Maps (was Re: Development process in the Ada community) Date: Fri, 19 Apr 2002 10:23:10 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: References: <3CB46975.90408@snafu.de> <3CBAFFEE.2080708@snafu.de> <4519e058.0204171036.6f0a7394@posting.google.com> <3CBDD795.4060706@snafu.de> <4519e058.0204180800.44fac012@posting.google.com> <3CBF0341.8020406@mail.com> <4519e058.0204190529.559a47ae@posting.google.com> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1019226193 8759 136.170.200.133 (19 Apr 2002 14:23:13 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 19 Apr 2002 14:23:13 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:22810 Date: 2002-04-19T14:23:13+00:00 List-Id: "Ted Dennison" wrote in message news:4519e058.0204190529.559a47ae@posting.google.com... > > I've actually been thinking along similar lines. What I'm wondering is > if we should keep the list package as "Lists.Unbounded", or if we > should just bag the whole bounded/unbounded issue and make it "Lists". > > O.K. Let's cash in our reality checks and see if they bounce. Would it be fair to say that *most* Ada developers and applications are some flavor of Windows/Unix with no realtime requirement beyond "Don't run so slow as to annoy the user..."? If that's the case, then we're looking at virtual memory machines that probably run very fast and hence, having fixed or bounded lists doesn't seem like it would be very important. If we put out a Grace.Lists and a Grace.Maps, that would certainly be a really good start. If at a later point in time there was some kind of groundswell indicating that there really was a need for bounded versions, why couldn't we go with Grace.Lists.Bounded as an extension? The only reason I can think of is that it isn't consistent with Ada.Strings. An interesting observation: When I write most apps for a PC in Ada, I tend to use the standard, fixed strings only at the points where Ada defined functions require them. (Stuff like Text_IO) The rest of the time, I just go to Unbounded because from a programming perspective, its just so much more convenient. In most instances, whatever performance penalties might exist for it are so far below the noise floor that they are invisible. Is this experience unique to me or would most Ada programmers report similar experience? If Ada were to totally abandon fixed and bounded strings (in the sense that they were never there - not from any sort of compatibility perspective), would you notice or care most of the time? (Presuming you could get them via some add-on package of your own creation if you ever really needed them?) My inclination would be to make Grace.Lists and Grace.Maps and add children at a later date if we thought we needed special cases. I'd again make an appeal for some version of "Grace.Containers.Lists" and "Grace.Containers.Maps" (or some variant thereof) so that there might also be easy extensions like: "Grace.Linear_A", "Grace.Statistics", "Grace.XML", "Grace.Whatever_Else_Seems_Like_A_Good_Idea"... The names aren't real important to me but thinking along the line of problem domains & dividing things up under a subheading is something I think would be beneficial in the long run. > > > > If the Lists specification is considered done, perhaps its time to look at > > it with an eye towards proposing a Map specification? > > Indeed. I still don't have the website up unfortunately (I've never > used ssl before, which is required to upload things, so I'm having > "issues".) But the last published proposal spec is still available at > http://www.telepath.com/dennison/Ted/Containers-Lists-Unbounded.ads.html > to refresh everyone's memory. > I've still got the link bookmarked and could possibly spend some time developing some test code, etc., if you think that's of value. (Do you have a body in some preliminary state I could work to?) I don't think you need to have the full-blown project setup done in order to discuss an interface to Maps. What would you suggest as a means of getting that ball rolling? Would you like someone to take the Lists spec and turn it into a strawman for Maps? (I hear you're a little preoccupied at the moment... :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com