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,70414f56d810c10c X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.68.8.229 with SMTP id u5mr1105266pba.0.1316678805792; Thu, 22 Sep 2011 01:06:45 -0700 (PDT) Path: lh7ni2408pbb.0!nntp.google.com!news1.google.com!goblin1!goblin.stu.neva.ru!feeder.news-service.com!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: discriminant questions Date: Thu, 22 Sep 2011 10:07:02 +0200 Organization: cbb software GmbH Message-ID: <1malv6h6q31j3.uz9ws5j0glnm.dlg@40tude.net> References: <9f37b726-d80b-4d24-bf3f-28a14255f7fd@s20g2000yql.googlegroups.com> <0d272f62-67d0-4905-972c-8a7e912c5531@en1g2000vbb.googlegroups.com> <148cxoyabima2.16mz6xwdph2hj.dlg@40tude.net> <01a1374f-59ab-40be-9e39-0640cb2a513d@n35g2000yqf.googlegroups.com> <1fp2o673mu9az$.d9loz1zbcl0d.dlg@40tude.net> <14tiipigyejtc$.hyp7e82egqwq$.dlg@40tude.net> <34d856bd-19a3-4bbf-b9d8-c0f100000ef4@k7g2000vbd.googlegroups.com> <1tpl2pc36ptr4$.txv4v3wmkjlm.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news1.google.com comp.lang.ada:18085 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: 2011-09-22T10:07:02+02:00 List-Id: On Wed, 21 Sep 2011 13:51:43 -0700 (PDT), Maciej Sobczak wrote: > On Sep 21, 9:48�am, "Dmitry A. Kazakov" > wrote: > >>> Nobody is forcing referential semantics, although it might be the most >>> natural and efficient solution for iterators. >> >> Of course it does, because the iterator refers to the container and to an >> element in that container. > > Not necessarily. > > Think about a map. Let's say a map with strings as keys. > We can say that strings are associated with values in the map and that > strings allow to obtain those values. But can we say that strings > refer to those elements? Strings alone do not. In a combination with a reference to the map, that new object does. > So let's define the iterator as an entity that is associated with the > element in a container and that allows to obtain that element. String is not an iterator according to this definition. It is also not an index (with operations Succ, Pred, or that I in A and J in A => I+J/2 in A). For generic programming the properties of the index, key, iterator must be stated. > So - no referential semantics is needed to define iterators. The validity of an iterator does not depend (pretends to) on other objects (unconditional). The validity of an index is conditional to the object the index is being applied. This is the semantic difference between them from which the usage and other issues like types relationships follow. >> Which is evidently fragile as any reference when >> the container and its element mutate. > > That is, the validity of an iterator is tied to the mutability of the > container. It is fragile in the same way as array indices, since they > become invalid when the array is reorganized. An index is neither valid nor invalid without a context. When index and container are combined into an iterator bound to certain element of the container (whereas the element's identity definition is a separate issue, let's for a while consider that there is a way to identify the element), then that reference might become invalid. The point is, when you use index as an iterator you get all problems of the latter. Indices are *assumed* to change when the container mutates. >> It is also bad for generic >> programming, because the semantics of the side-effects depends on the >> implementation, i.e. the internal structure of the container. > > Not convincing - generics are supposed to have well defined specs. I meant rather generic programming = programming in terms of sets of types. > If > you worry about your side effects being bound to implementation, then > there is something wrong with your model of generics. Don't blame > iterators for this. I blame them because these differences, essential to container usage, cannot be promoted at the interface level. Consider a generic implementation of removing all elements of the container using iterators: This := Container.First; while This /= Null_Iterator loop Next := This.Next; This.Delete; This := Next; end loop; This may work or not depending on the semantics of Delete. E.g. for a circular list, it will loop forever. Note that referential semantics has its place. My concern is its overuse for things which don't require it, or even cannot provide it, e.g. arrays. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de