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,a644fa9cd1a3869a X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-10 09:21:15 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsmi-us.news.garr.it!newsmi-eu.news.garr.it!NewsITBone-GARR!elvis.franken.de!chico.franken.de!uni-erlangen.de!news-nue1.dfn.de!news-han1.dfn.de!news.fh-hannover.de!news.cid.net!news.enyo.de!news1.enyo.de!not-for-mail From: Florian Weimer Newsgroups: comp.lang.ada Subject: Re: List container strawman 1.2 Date: Sat, 10 Nov 2001 18:39:58 +0100 Organization: Enyo's not your organization Message-ID: <87d72qfrtd.fsf@deneb.enyo.de> References: <3BECA3B7.5020702@telepath.com> <87668ivpw8.fsf@deneb.enyo.de> <_wcH7.20057$xS6.32511@www.newsranger.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cancel-Lock: sha1:/S+n0YA3Tx5GDWIf2hDF8gRxrFg= Xref: archiver1.google.com comp.lang.ada:16226 Date: 2001-11-10T18:39:58+01:00 List-Id: Ted Dennison writes: > In article <87668ivpw8.fsf@deneb.enyo.de>, Florian Weimer says... >>You should not call it a "bounded error" because that would be >>confusing. Such errors result in erroneous execution with typical >>implementations. For debugging, we might add an additional variable > > I thought the whole point of "bounded errors" was that they *don't* > result in erroneous executions. Oops, sorry. "Such errors" referred to errors in using the list container routines, IOW these usage errors can lead to erroneous execution. > That's a technique I have to say I've never used in final production > code, and is certianly not used anywhere in the rest of the current > Ada library. What about pragma Assert? It's similar. > Exactly what benifit would we get from this? You would get a debugging version without the need to duplicate a lot of code. > I don't think you can use it to switch between safe active iterators > and unsafe "Locations", as the declarations would have to be > different too. 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). But perhaps it isn't worth the trouble, I don't know. >>What about terminating Iterator prematurely using an exception? It's >>a bit ugly, granted, but with the "out" parameter approach, I've >>managed to forget to set the parameter more than once. If the Quit >>parameter is going to stay, we shouldn't use a Boolean type for it, >>but a new enumeration type. > > I suspect we would have some violent objections to that idea from > some people Yes, of course, and I understand these objections. > What would you say to the proposal we had to make it "in out" with a > default? That's probably better. I think we can assume that most of the time, the user wants to iterate over the entire structure, so we could specify a default value of "Continue", and in many cases, the user wouldn't have to deal with this parameter at all. 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. (And I wouldn't include the stream attributes in the main package, but in a child.)