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,7ee10ec601726fbf X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-31 10:09:17 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!newshub2.rdc1.sfba.home.com!news.home.com!sjcppf01.usenetserver.com!usenetserver.com!news-west.rr.com!lsnws01.we.mediaone.net!typhoon.san.rr.com!not-for-mail Message-ID: <3BE03E54.57E0E6C8@san.rr.com> From: Darren New Organization: Boxes! X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: why not 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> <3BDEF0FE.B55FED9E@san.rr.com> <9rmuqi$es$1@nh.pace.co.uk> <3BDF1F13.4B99361C@san.rr.com> <9rnbtv$5i4$1@nh.pace.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 31 Oct 2001 18:09:39 GMT NNTP-Posting-Host: 66.75.151.160 X-Complaints-To: abuse@rr.com X-Trace: typhoon.san.rr.com 1004551779 66.75.151.160 (Wed, 31 Oct 2001 10:09:39 PST) NNTP-Posting-Date: Wed, 31 Oct 2001 10:09:39 PST Xref: archiver1.google.com comp.lang.ada:15492 Date: 2001-10-31T18:09:39+00:00 List-Id: Marin David Condic wrote: > Well, we aren't exactly seeing a huge consensus here about what people want, > right? :-) I think everyone is pretty much agreeing that what's needed are lists and maps, both task safe and efficient versions. The rest is just details. ;-) > I just think it would be easier to start with something that is informally > used in lots of places before proposing a change to the Ada standard with > something with which there is potentially little experience. No question. But then it's harder to precisely specify what the behavior is without saying "it behaves like this implementation." > I think you'll find the compiler vendors are the ones who would raise > objections to a container library as an appendix. Maybe I shouldn't try to > state their case for them, but prior discussions seemed to go in the > direction that it would be hard to write a verifiable standard and that the > language standard wasn't the proper place for it. Right. And my point was that for simple data structures, it's really not that hard if you use the appropriate tools, like ADTs. It's very easy, for example, to specify what a sort routine does, without looking at the implementation at all. Just as performance is difficult to describe unless you know about Big-Oh notation, verifiability is difficult unless you know about the mathematical tools that let you do verification. Even things like specifying tasks isn't all that difficult. Verifying it in complex situations can be harder, sure. > Since apparently C++ has succeeded in including a similar library in its > standard, I wouldn't think the task is either impossible or totally > undesirable. I'd just favor a more gradual approach. But have they succeeded? It took years before any of the STL implementations were compatible and correct, IIRC. > But if you want to crusade to get the Booch Components or some other > collection of containers adopted as an appendix to the ARM, I won't try to > stop you. Me, personally, I'd like to have container classes that are simpler, since I'm only up to doing simple stuff so far with Ada. Other folks do wild and wooly complex deep-magic stuff with Ada, and then make it blow up. ;-) I'm not sure it would be easy to write one library that works well for both, just because of how complex Ada is. As far as what the spec looks like, I'd like to see the collection classes defined as ADTs, with restrictions on the order statistics of the implementations. Kind of like the AT&T C++ libraries. Personally, I'd also think that a couple of relatively simple structures (like, an Unbounded_Array paralleling Unbounded_String, some sort of efficient Map, some sort of sorted/sortable relational-database-like table allowing one to sort on multiple columns, select multiple rows, etc) would be a good start for collection units. A set of units for some general stuff like logging and configuration and inter-process synchronization would be helpful. Stuff to manage directory manipulations (scanning for files in a directory, deleting files, creating directories, setting permissions, etc) would be good. I also think a nice internet library would be useful as well, at least for me. Something to parse MIME and XML, something to handle sockets, something for FTP and POP and SMTP and CGI and such, something for TLS/SSL. I think I've seen pretty much all of this out there, except maybe the MIME parser. Of course, all this would need to be at least mostly-portable and supported, but most of all available in a fairly centralized place where it's easy to find. Maybe this kind of resource is already out there and I just have either not really found it or I've not looked at it long enough or it just needs a slightly better index or something. (I know about adapower, thanks ;-) Anyway, I guess I'll stop babbling now. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. Sore feet from standing in line at airport security checkpoints: Jet Leg.