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,8eff44ec1bcf8433 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-25 15:05:23 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!btnet-peer0!btnet-peer1!btnet!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: Container reqs Date: Thu, 25 Oct 2001 17:18:33 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9r9vja$f3f$1@nh.pace.co.uk> References: <9qctpn$lil$1@news.huji.ac.il> <3BCA86C7.BB252751@acm.org> <%jYy7.31350$ev2.37672@www.newsranger.com> <3BCD7C50.647ADBD0@brighton.ac.uk> <9qk44b$utk$1@news.huji.ac.il> <3BD527A8.93C1F68B@brighton.ac.uk> <9r3umu$hvo$1@news.huji.ac.il> <9r4mr9$os0$1@nh.pace.co.uk> <9r5ues$ns6$1@news.huji.ac.il> <9r6i04$o1r$1@nh.pace.co.uk> <9r9rqj$5dh$1@news.huji.ac.il> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1004044714 15471 136.170.200.133 (25 Oct 2001 21:18:34 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 25 Oct 2001 21:18:34 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:15200 Date: 2001-10-25T21:18:34+00:00 List-Id: We're probably not far off in terms of goals and objectives. I'd just like to actually see something emerge from this process that has a concrete result and a significant benefit to Ada. My fear is that with an informal sort of process like this, it will drift in too many directions for too long until eventually interest wanes and we don't see anything come of it. Its a problem for volunteer projects. If there were a dozen of us getting paid to do it and we had a deadline, I have every confidence that we'd hammer out something. As it is (and without some indication of support/endorsement from vendors) its hard to see a concrete result emerging any time soon. By "Lists" I have in mind a dynamically allocated, doubly linked list. In my experience, things like stacks and queues (at least dynamic ones) are just a subset of calls to a doubly-linked list and so they don't get used much in practice. (We could debate for hours the relative merits and usefulness of static/dynamic stacks/queues/lists/double-lists/etc. All that is "nice" and "interesting" but I think that just getting a doubly-linked-list package available would probably handle enough practical conditions that it would get beat to death in normal usage.) I would note that the MFC basically provides some version of Lists and Maps and no other particular data structures. (Depending on what arguments one wants to have about what constitutes a "Data Structure". I'm thinking about just a general container kind of thing.) Hence getting just that far would bring us up to par with MSVC++ in that area. Not that I want to duplicate everything in the MFC, but lots of people write lots of code using it and they get lots of mileage out of Lists and Maps available to them there. It isn't *everything* but it is, as I have observed, A Good Start. Now I can see the point about wanting to get the right concepts together so that extensions don't start becoming a problem. Should these be generic or some form of OO Inheritance? (I'm thinking generic for a "basic" set) Should they have private, limited and/or tagged parameters? (I'd start with "Basic" as the rule and create variants - make a set with private parameters and clone them off for limited/tagged usage.) I'm still hoping to see some support for a basic set of data structures. Take a look at the standard/semi-standard libraries that come with other languages or products and you can see signs that they did not start out in life with "The Grand, Unified, Theory Of Code Libraries" guiding their every development. Most of them look like they started out small and had branches and wings added on to them over time. So long as the initial development doesn't hopelessly hamstring future add-ons, and the initial cut at it provides some useful, core tools, I'd think we had something O.K. to adopt and build on. Heck! I'd get on board with one of the existing packages if there was some emerging consensus from the users and some buy-in from the compiler writers. So far, there seems to be neither, so I think it would be better to come up with some small core of things that *could* be agreed upon as being generally useful and *might* get some buy-in from the compiler vendors. I don't know if I'm a lone voice crying out in the wilderness over this or not. I'd suspect that most Ada users would be happy to see their compiler come with a library full of stuff they could use with some confidence that it would be portable to other compilers and didn't require a masters degree in CS to figure out how to use. I hope we can get that far. 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/ "Ehud Lamm" wrote in message news:9r9rqj$5dh$1@news.huji.ac.il... > I agree with almost all your points. > > Indeed we can start with some minimal number of conponents, and build on > from there. I also agree that endless debates, are - well - endless... > > My only concern is that without some overall design, you'll end up with a > pile of packages, and not one consistent library. > I want things to compose nicely, and be extendable. > > That's also why I agree that debating the various existing libraries, though > educational is not "good for the cause". > > Still, I'd feel better with something organised by ADT properties. Thus MAPS > are fine, where as I'd like clarification about Lists. Are we talking > sequential structures, or about the implementation as linked sturctures? > > I prefer maps, queues, dequeues etc. > > Ehud > >