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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: A few questions Date: Fri, 13 Nov 2015 09:40:29 +0100 Organization: cbb software GmbH Message-ID: <1dolqizyi8gxi.t3173bhifuu1.dlg@40tude.net> References: Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: TWQ9mg4k1m/sph/eQ+zHLA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:28354 Date: 2015-11-13T09:40:29+01:00 List-Id: On Thu, 12 Nov 2015 15:15:45 -0600, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:hs9mu83acmqt$.5liwfglzrr7q.dlg@40tude.net... >> On Thu, 12 Nov 2015 12:28:46 -0600, Randy Brukardt wrote: >> >>> Personally, I find the "of" form unnecessary; we've iterated arrays for >>> decades without direct access to the element (using the "cursor", that is >>> the array index), so why are containers different? >> >> Of course it is different. Index does not iterate array, it does the >> array's index range. That is the difference. >> >> You can iterate elements of a container or indices of a container. It is >> not same. > > Surely it is not the same. But why do we need the first? For doing this: for Line in Read (Text_File) loop ... end loop; Operation Read provides an iterateable container-view of Text_File. There cannot be any index, because the "buffer" will contain just single line. Providing index will be error-prone and cause run-time overhead (index checks). Add here naming issues, you need a name for the container-view: for Line_No in Read (Text_File) loop declare Next_Line : String := ??? (Index + 1); -- Oops! begin ... end; end loop; An array interface would promise more than there actually is. It would be bad design. > An array is surely > a container, and we got along just fine for 30 years without being able to > iterate elements of arrays. Not every container is an array. There are lots of containers which semantically have no index. > There is absolutely no difference for any other > sort of container (especially as the array syntax can be used for any > container). It cannot be, e.g. for a general case graph, but that is another story. > Iterating on elements of a container is unnecessary overkill. (It's also > harmless overkill, unlike, say, anonymous access types). > >>> Especially as the >>> indexing form works on all of the language-defined containers (you never >>> need to explicitly call Reference or Element). So an "in" iterator looks >>> just like the array iteration that we've been using from the beginning of >>> time. What's so hard about that? >> >> There could be cases when a container does not have any natural index. E.g. >> a bag, a set, a files directory etc. You could iterate elements of without >> inventing indices. Especially when the index is volatile. Consider an >> implementation that gets a result set of a DB query and then iterates the >> result. > > There is always *something* that works as an index. If there isn't, you > can't iterate (because you can't figure out a reproducible order for which > item is next). First, index is more than iteration. Index assumes random access and an ability to access any number of times. Iteration requires only sequential access and only visit once. If you equate both, you either burden the implementation with unnecessary functionality or the clients in order to catch unsupported actions. Not good. Secondly, it is an implementation driven view. The problem space may have no index even when the implementation could have one. Exposing implementation details is bad. > In any case, Ada does not support iteration without something > being a cursor; the "of" form of iteration is a direct translation of the > "in" form of iteration (it's purely syntactic with no semantics of its own). Yes, Ada has a lot of issues with abstract interfaces. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de