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.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_FROM_MSSP autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a644fa9cd1a3869a X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-12 13:57:25 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-out.visi.com!hermes.visi.com!newsranger.com!www.newsranger.com!not-for-mail Newsgroups: comp.lang.ada From: Ted Dennison References: <3BECA3B7.5020702@telepath.com> <3BF0247D.4500975E@san.rr.com> Subject: Re: List container strawman 1.2 Message-ID: <5BXH7.22252$xS6.34813@www.newsranger.com> X-Abuse-Info: When contacting newsranger.com regarding abuse please X-Abuse-Info: forward the entire news article including headers or X-Abuse-Info: else we will not be able to process your request X-Complaints-To: abuse@newsranger.com NNTP-Posting-Date: Mon, 12 Nov 2001 16:57:21 EST Organization: http://www.newsranger.com Date: Mon, 12 Nov 2001 21:57:21 GMT Xref: archiver1.google.com comp.lang.ada:16374 Date: 2001-11-12T21:57:21+00:00 List-Id: In article <3BF0247D.4500975E@san.rr.com>, Darren New says... > >This is a multi-part message in MIME format. >--------------AC397429692108B025B90E25 >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit I can't always read all parts of a MIME message w/ my regular newsreader. In this case, your spec came through as garbage. >> No_Item : exception; >> function Pop_Front (Source : List) return List; >> function Pop_Back (Source : List) return List; > >I think calling it "Front" and "Back" here and "First" and "Last" later >is going to be confusing. Perhaps. But then First and Last make perfect sense in terms of iterating, and make it clearer which way "Next" and "Previous" go, so I think the terminology there is better. "Font" and "Back" are pretty standard terminology for list ends, so from that standpoint they should stay too. What would you prefer to see here? >> >Inserting one list into another seems like overkill. If we're going to >> >> It seemed that way to me too when suggested, but no one else said anything of >> the sort, and its easy enough to code up. I'm still unconvinced that this is >> something that folks would have to do a lot. > >I do it all the time in list-oriented languages. When you have a bunch >of lists you want to merge into one, it's very handy. It makes no sense >to leave it out, really, since it's not something you can easily code up >yourself. If all you want is to tack them together, the "&" functions do that just fine. Do you actually need to merge lists by sticking one into a specific place in the middle of the other all the time? "next" should move the current value of a pointer, rather than returning >the next pointer after this one, or you'll have a hard time keeping >track of what "positions" might be valid. No, its actually *no* tougher to keep track of valid positions either way. Even with a limited position you have to worry about the possibility that one position may go invalid due to operation on another position. (Or alternatively, you don't worry about it in either case, which is what the current strawman does). The data structures and methods for keeping track of this are the same as they would be for non-limited positions. Making them procedures and/or limited really buys you nothing, and prevents some very useful constructions for those of us who like to do all the work we can in our declaration sections. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html No trees were killed in the sending of this message. However a large number of electrons were terribly inconvenienced.