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-10 10:31:50 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!nntp-relay.ihug.net!ihug.co.nz!out.nntp.be!propagator-SanJose!in.nntp.be!newsranger.com!www.newsranger.com!not-for-mail Newsgroups: comp.lang.ada From: Ted Dennison References: <3BECA3B7.5020702@telepath.com> <87668ivpw8.fsf@deneb.enyo.de> <87d72qfrtd.fsf@deneb.enyo.de> Subject: Re: List container strawman 1.2 Message-ID: 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: Sat, 10 Nov 2001 13:31:02 EST Organization: http://www.newsranger.com Date: Sat, 10 Nov 2001 18:31:02 GMT Xref: archiver1.google.com comp.lang.ada:16233 Date: 2001-11-10T18:31:02+00:00 List-Id: In article <87d72qfrtd.fsf@deneb.enyo.de>, Florian Weimer says... > >Oops, sorry. "Such errors" referred to errors in using the list >container routines, IOW these usage errors can lead to erroneous >execution. I used the term "bouded error", because it seems to me that the limits for what nasty things can happen is definable. Its probably not worth wasting this much breath over though. :-) >What about pragma Assert? It's similar. It's also Gnat-specific. Anyway, I think it would be easier for acceptance of this facility if there were one implemtation (spec and body) that could (not must but could) be used by any compliant compiler vendor. >Hmm, I haven't completely followed the discussion, but there was a >proposal for including a list pointer in the Location/Position type, >and it made sense to me. If this proposal is followed, all data would >be there to verify these operations (the only thing missing is >verification of the list access value itself). Even if we did that, the declarations of List and Location in the private part of the spec would have to be different depending on what approach is used. That's why we don't want to move to a reference implementation for the body until we get this issue resolved. >BTW, there's an unnecessary negative in the Sort routine: > > generic > with function Reverse_Order (Left, Right : in Element) return Boolean; > procedure Sort (Subject : in out List); > >I think it would be better to test for "In_Order" ("<=") because this >seems to be more natural. In addition, we should probably specify if >Sort is stable or not. You have a point. My thinking was that since the routine is a boolean, and can be substitued with any matching function whatsoever, its generic name should say what action needs to be done when the condition is true, rather than stipulating the conditions under which *nothing* will be done. Perhaps some comparative code would help folks decide: Assume: package Integer_List is new Containers.Lists.Unbounded (Integer); Version 1: procedure Sort_Increasing is new Integer_List.Sort (Reverse_Order => ">"); Version 2: procedure Sort_Increasing is new Integer_List.Sort (In_Order => "<"); I'm not sure what you mean by "Stable". If you mean some flag will be set and every insertion after that will also call "Reverse_Order" to keep things sorted that way, I'd say no. Hmmm. I'd meant to add an "Insert_Sorted" routine for that issue. Perhaps you were leading up to that. --- 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.