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=unavailable 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!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: A few questions Date: Fri, 13 Nov 2015 11:41:02 -0600 Organization: JSA Research & Innovation Message-ID: References: NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1447436463 17611 24.196.82.226 (13 Nov 2015 17:41:03 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 13 Nov 2015 17:41:03 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:28358 Date: 2015-11-13T11:41:02-06:00 List-Id: wrote in message news:db3ea03a-07cc-4f1a-96aa-a7a18d5e2145@googlegroups.com... > 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: No, you couldn't, because there still is no way for the compiler to identify the container to pass to the Reference aspect. If you mean to magically extract it from the call to Depth_First_Search, I would be strongly against as there is no need for an actual container object for an iterator (and the model specifically was designed to allow that possibility). It would be *much* more limiting to assume a container. I suppose you could add a third aspect to specify which parameter is the container, and then use additional magic to add a renames of that parameter (with all of the attendant restrictions on what that parameter could be). Definitely a lot more complicated than what we have (and what we have is too complicated). > for E of G.Breadth_First_Search loop -- breadth first search, get > element > null; > end loop; Again, how does the compiler know that G is the container in this iterator? "G.Breadth_First_Search" is just a function call. On top of which, you now have two different and unrelated expected types for the iterator, which would be a new concept in Ada. > 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. Well, I disagree. The iterators are certainly a first-class type, so long as you use the "in" form. And it's impossible to use the "of" form for all possible iterations; it's way too limiting for the general case. >> 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. Umm, no, the goal is to provide new capabilities to allow Ada to solve additional problems. (Pre and Post are definitely new capabilities - see the class-wide versions and 'Old; pragma Assert was too much of a blunt instrument to be of much use.) Making a language "more expressive" is code for "easier to write", which never was a goal of Ada. To the extent that we've made the language "more expressive", it's been to make ADTs more like the capabilities of the built-in types (for instance, arrays). Going beyond that is unnecessary and probably harmful. > 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" ? Readability, of course. I don't believe that you should ever have been allowed to just specify E. I lost that argument 'cause it wasn't sufficiently evil to waste scarce political capital on, but I don't see any reason to expand the evil, or worry because it doesn't work in some cases. (That was clearly understood when we defined it; it was intended to be a quicky shorthand, not the way to do most iterations.) Randy.