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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,f2690a5e963b61b6 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news2.google.com!proxad.net!proxad.net!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: GCC 4.0 Ada.Containers Cursor danger. Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1120474891.635131.216700@g44g2000cwa.googlegroups.com> <1120575076.876798.108220@g44g2000cwa.googlegroups.com> <1120583470.429264.325450@g43g2000cwa.googlegroups.com> <42cb8d21$0$22761$9b4e6d93@newsread2.arcor-online.net> <42cd064c$0$10817$9b4e6d93@newsread4.arcor-online.net> <42cda8c4$0$22780$9b4e6d93@newsread2.arcor-online.net> Date: Fri, 8 Jul 2005 10:48:12 +0200 Message-ID: <1u3hh2597i4ne$.1ryetugksbmus.dlg@40tude.net> NNTP-Posting-Date: 08 Jul 2005 10:48:12 MEST NNTP-Posting-Host: 40cd0e1a.newsread4.arcor-online.net X-Trace: DXC=>>c\?G>8b1=_78OXD477\?:ejgIfPPld4jW\KbG]kaM8liQbn6H@_E9?f700Hl:;R<[6LHn;2LCV>7enW;^6ZC`4<=9bOTW=MN> X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:11960 Date: 2005-07-08T10:48:12+02:00 List-Id: On Fri, 08 Jul 2005 00:12:11 +0200, Georg Bauhaus wrote: > Dmitry A. Kazakov wrote: >> On Thu, 07 Jul 2005 12:38:57 +0200, Georg Bauhaus wrote: >> >>>> Otherwise iteration using cursor >>>>would be impossible. >>> >>>Why? A cursor designates an element. There are operations >>>on cursors, some of them let us move a cursor from one >>>element to another. Then the cursor designates another element. >> >> Rather it does some element at another location. > > As long as we have no clear definition of "location", > the argument can go on. That's easy. Enumerate all elements in the container [i.e. define an order there.] Location will be that number 1..n. > Certainly there are relative > locations if you think of a List say, this element comes > before that. There are locations implied by sorting order. > But sorting order depends on the comparison, so location > is in fact not a spatial position, but there is a position > in some sorting order. Which then isn't fixed per > element in a container. Yes. > Then I might imagine an element > designated by a cursor to have a place in some imaginary > picture, hence to have a location. But I can dispense with > a location when the container's cursors actually synthesize > the elements on read, so elements don't exist at all before > --in this imaginary implementation-- my program dereferences > a cursor. The elements could be stored in some electrically > charged gel, highly dispersed. Or I could be your container > as long as my operations will give you what the operation > descriptions tell. Do I have to tell you where (and whether) > I store your information in locations? You did, if elements are ordered. >> The element is of little >> matter here (for this concrete case, note.) Otherwise "Replace" would have >> no sense. > > Sorry, I don't understand this. Replace = "to take or fill the place of". Notice "the place of"! (:-)) >> BTW the parameters of the type Cursor are routinely named >> "Position"! > > Anything better? "Element", isn't cursor <=> element? (:-)) >>>I don't think there an implied requirement to think of locations. >> >> Then you have to throw out "Next", "First" etc. > > I don't understand. I'm just thinking in terms of elements > and cursors that designate elements. But the elements type don't have "Next" and "First". If Integer X is in A then Integer'Succ (X) is not necessarily in A. And A'First is not necessarily Integer'First. > There are subprograms > named Next, First, etc. with a description of what they do. > Where is the pressing need for a location? How do you use > "location" in your programs? A (Location) := X; >> It is the location that tells you what's next. > > Next is providing me with something that designates > another element, or No_Element. > To me, that's what is next, plus what Has_Element says. > By the operations of Next, First, etc., I don't know yet what's > next. I will know what is next when I look at the element > designated by the next cursor, after Next's execution. >> As I said before, it is difficult if possible to assign any definite >> semantics to cursors, such that would be consistent across all operations >> on them. > > Could you explain some inconsistencies among the Cursor > operations? What is the semantics they implement? See your example with Next. We have: 1. An order defined on elements (=locations in some "pre-container" (:-)) 2. An order defined by the container (=locations) 3. Instances of elements (value semantics) 4. References to elements (=locations in some third container! (:-)) We need to define what "Next" does in terms of 1-4. I doubt you will be able to define it without 2. Note that you could replace 2 with 2.a A membership test for an element to be in the container But then 2 could be trivially derived from 2.a and 1. In other cases 2 could be an order completely unrelated to 1, like it is in the case of unsorted arrays. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de