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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.68.227.9 with SMTP id rw9mr16852817pbc.12.1447404347208; Fri, 13 Nov 2015 00:45:47 -0800 (PST) X-Received: by 10.182.81.130 with SMTP id a2mr25363oby.20.1447404347169; Fri, 13 Nov 2015 00:45:47 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!i2no1284808igv.0!news-out.google.com!l1ni2748igd.0!nntp.google.com!i2no1284804igv.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 13 Nov 2015 00:45:46 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=194.98.77.125; posting-account=6yLzewoAAABoisbSsCJH1SPMc9UrfXBH NNTP-Posting-Host: 194.98.77.125 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: A few questions From: briot.emmanuel@gmail.com Injection-Date: Fri, 13 Nov 2015 08:45:47 +0000 Content-Type: text/plain; charset=ISO-8859-1 Xref: news.eternal-september.org comp.lang.ada:28355 Date: 2015-11-13T00:45:46-08:00 List-Id: On Thursday, November 12, 2015 at 7:28:49 PM UTC+1, Randy Brukardt wrote: > That doesn't make sense, though, as the iterator interface doesn't contain > the information necessary to do "of" iteration. In particular, it doesn't > provide the container or Reference function -- nor could it, as there may > not be a container. Absolutely, we cannot do that with Ada, as defined in the standard. But that's exactly what I am complaining about. The aspects should have been defined on the Iterator, not on the container itself, as in: type Graph is tagged private with Default_Iterator => Depth_First_Search; type DFS_Iterator is private with Reference => Reference, Iterator_Element => Element_Tye; function Depth_First_Search (Self : Graph) return DFS_Iterator; type BFS_Iterator is private with Reference => Reference, Iterator_Element => Element_Tye; function Breadth_First_Search (Self : Graph) return BFS_Iterator; With such a separation, I could then do something like: G : Graph; for E of G loop -- depth first search null; end loop; for E of G.Breadth_First_Search loop -- breadth first search, get element null; end loop; for C in G.Breadth_First_Search loop -- breadth first search, get cursor null; end loop; The aspects were put at the wrong level, and iterators end up being hidden magical objects, rather than first class citizens with their own role in the design of containers. > 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? 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 are lots of things we have been doing for decades. We have been inserting explicit tests and asserts, and now we are adding pre and post conditions, just to find one example. Languages evolve, as you well know of course, and the goal is to make them more expressive. I like to clearly state what I mean in the code, but on the other hand why should I have to specify "Element (C)" when I can just use "E" ?