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.66.139.193 with SMTP id ra1mr23706682pab.17.1447531027826; Sat, 14 Nov 2015 11:57:07 -0800 (PST) X-Received: by 10.182.250.169 with SMTP id zd9mr264935obc.1.1447531027776; Sat, 14 Nov 2015 11:57:07 -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.swapon.de!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!i2no3205102igv.0!news-out.google.com!f6ni2555igq.0!nntp.google.com!i2no3205094igv.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 14 Nov 2015 11:57:07 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=88.181.126.208; posting-account=6yLzewoAAABoisbSsCJH1SPMc9UrfXBH NNTP-Posting-Host: 88.181.126.208 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <5007b311-5d2e-448c-b8c8-fc2e2d88ea5e@googlegroups.com> Subject: Re: A few questions From: briot.emmanuel@gmail.com Injection-Date: Sat, 14 Nov 2015 19:57:07 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Received-Bytes: 5109 X-Received-Body-CRC: 904797413 Xref: news.eternal-september.org comp.lang.ada:28366 Date: 2015-11-14T11:57:07-08:00 List-Id: > No, you couldn't, because there still is no way for the compiler to identify > the container to pass to the Reference aspect. You seem to be mixing the particular implementation you would use with what the standard should allow. There is nothing in the spec of a reference type that mandates knowing the container (and the way it currently is done in the implementations is to use a 'Unrestricted_Access, which is ugly to say the least). > 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. If I want my iterator to implement depth_first_search, it would indeed need to know the container (like most iterators would need to know the container, in fact). The reference type itself (the end product of the iteration) doesn't need to know that though. The container is necessary for the iteration or traversal of itself, but certainly not once you manipulate an element. My example assumed nothing. The implementation you seem to have in your head seems indeed to assume a lot of unnecessary things. > Definitely a lot more complicated than what we have (and what we have is too > complicated). What we have is both too complicated and too limited. Too complicated because nobody that hasn't spent a full week will be able to explain how the aspects combine with iterators to end up with cursors and the for-of loop. They just happen to work for existing containers, but as this thread has proven, anyone who tries to actually implement them for other uses that the few official containers quickly hits sever limitations. > > > 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. It is a function call that returns the iterator. So obviously it is allowed to have a relationship between the return value and the parameters. The iterator is therefore allowed (but not mandated, that would depend on the actual container we are talking about) to have a reference to the container. This is called flexibility. Something lacking in the current standard. I do not understand your last sentence about the two unexpected types. > Making a language "more expressive" is code for "easier to write", which > never was a goal of Ada. That's one of the issue here. The goal for Ada, as I understand it, has always been to be "easier to read". There is no reason why "easier to write" should be in opposition to that goal. > > 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 Now I understand. You are re-fighting a fight you lost apparently. But from talking to all my colleagues (all of whom are of course Ada experts), we all much prefer the form with just "E" in practice. So that change was a great improvement in the standard, if not quite wide reaching enough.