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, LOTS_OF_MONEY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fdc75443ea18fb32 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-28 13:26:54 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!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: Standard Queue status Date: Wed, 28 Nov 2001 16:02:33 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9u3jdb$2i9$1@nh.pace.co.uk> References: <%QRM7.39743$xS6.65958@www.newsranger.com> <9u0qhb$pq5$1@nh.pace.co.uk> <9u0ujd$rhg$1@nh.pace.co.uk> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1006981355 2633 136.170.200.133 (28 Nov 2001 21:02:35 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 28 Nov 2001 21:02:35 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:17135 Date: 2001-11-28T21:02:35+00:00 List-Id: "Ted Dennison" wrote in message news:z9aN7.41127$xS6.69040@www.newsranger.com... > > I think I'd best say that I should shoulder a fair bit of the blame for that. > First off, I *asked* for more discussion when some were apparently ready to move > toward implementing what we had. I'd hoped a bit more polishing (particularly > anound the subprogram names and the implementation of the iterator) would > achieve us a broader consensus. > The names can always be changed before a final release - the important thing is that the concepts be acceptable because you can't change those once its started. The iterator scheme is something that has to be lived with once started. I'd favor "simple" since it is always possible to tack on a child package that provides more fancy schemes if it seems desirable. > > To get things back on track, I'd like to ask if there is anything in Nick's > proposal that there is general consensus on putting in the strawman (or we could > take it the other way, if that's what folks want). If you want to look at it, > the package in question is at > http://www.adaos.ukf.net/njr05/scl-lists-unbounded.ads.html . > I'll take a look but the page is not coming up at the moment. > Personally, I like his use of the "Direction" type to specify which end to start > from in his operations. I also like the ability to convert between lists and > unbounded arrays. I think those may merit putting in the final version. There > are also a number of operations in there that the strawman doesn't have which > some folks may find useful. > I wouldn't try to make the lists be all things to all people. KISS - then come up with fancier varieties that are variations on a theme. Extra operations can always exist in a child package. > On the other hand, I'm not a big fan of the iterator approach used. In an > "unbounded" package, I don't think the user should have to worry about running > out of resources like iterators. That sort of breaks the whole "unbounded" > philosophy. > Then keep the basic iterator you have in the Mark 1, Mod 0 package spec - alternative iterators can be added in a child package. Keep the scope small and simple enough that it is doable in some rational span of time and effort. Ada is nice in allowing extensions and enhancements as we go without upsetting the apple cart. > Also I think there are too many operations in there. The package spec is huge. > It has (by my count) 79 subprograms. The current strawman has 34, which to some > people it seems is annoyingly small, as we keep seeing suggestions for > additions. Perhaps in between there somewhere the truth lies. > If the subprograms can be broken into groups and the basic ones kept in the parent, then one or more child packages that provide enhanced capabilities is the way to go. Just because it is useful doesn't mean it needs to be in v1.0 or the parent package. Don't discard the ideas - just stall them off until we have something basic working and acceptable to the general public. > A large culprit here seems to be the unbounded-array support, which is probably > taken a bit too far. Its OK to convert between them, but anything much more > should probably be accomplished by first converting the array to a list. If we > take Ada.Strings.Unbounded as a model, only the infix operators should have > unbounded array equivalents. > Make an Unbounded Array a separate data type. Sure, its similar to a list, but maybe it should be its own specialized data type because its usage will be different and ultimately it may be better off with a different implementation. Conversions can be handled by child packages at a later time if it seems that they are needed. Just my $0.02 - I think this would make a good start. 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/