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: Mon, 16 Nov 2015 13:13:05 -0600 Organization: JSA Research & Innovation Message-ID: References: <5007b311-5d2e-448c-b8c8-fc2e2d88ea5e@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1447701186 19246 24.196.82.226 (16 Nov 2015 19:13:06 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 16 Nov 2015 19:13:06 +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:28405 Date: 2015-11-16T13:13:05-06:00 List-Id: wrote in message news:5007b311-5d2e-448c-b8c8-fc2e2d88ea5e@googlegroups.com... >> 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). Huh? You are suggesting an alternative description for the existing iterators for the existing containers. (If you're suggesting anything else, you're wasting everybodies time, 'cause something that won't work with the existing containers is a non-starter.) And the Reference function in the existing containers (and in any container I can imagine) takes a container parameter. That parameter has to come from somewhere, and it can't come from the iterator interface (it doesn't include a container in the description). So where does it come from?? Since 'Unrestricted_Access is GNAT junk, it's doesn't have any value for a sample implementation (if you really need 'Unrestricted_Access, then the interface can't be implemented in Ada, and that would be a major problem.) So far as I know, you might need to use 'Unchecked_Access, but that's necessary anytime one needs to get a pointer to save the evaluated version of something. ('Access being useless for 98% of uses; I've only once in my entire programming career been able to use 'Access rather than 'Unchecked_Access). >> 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. You're speaking nonsense. The element is part of the container, and the only way to access it is from the container. You can't create a reference to an element of a container without having the container. But your proposed interface does not have the container anywhere. How does the reference get created??? > My example assumed nothing. Your example is nonsense, IMHO. > The implementation you seem to have in your head seems indeed to assume > a lot of unnecessary things. ??? I'm mapping iteration onto the existing containers. That is straightforward with the existing description, but it's not possible with your proposed redefinition without some modifications. The current definition has a very specific expansion of shorthands into other, existing features. But that's not possible with your proposal. You seem to be expecting magic rather than explaining how to get from A to B, and that's not a possibility with the language standard. >> 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. The limitations aren't that severe, and seem mostly to be related to having the iterator object be an "in" parameter. (That's probably happened because "in out" parameters on functions seem weird, but they clearly make more sense in this case.) >> > 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. So the iterator has a reference to the container. How would it be used (references being something not related to iterators)? We certainly don't want to be introducing special reference routines *just* for iterators (that's the sort of extra complexity that would have never flown). As for "flexibility", there is plenty; people just seem to have a lack of imagination about this interface (see my replies to Dmitry). I agree that it would have been better if the iterator parameters had been "in out", but that's about it. You're imagining "sever" problems -- Brad had pretty good results with the ACATS test and with the directory iterators. These things aren't expected to be easy to write -- hardly anyone should be doing that anyway (much like generics) -- ease of use is paramount. > I do not understand your last sentence about the two unexpected types. "for E of G loop" -- The expected type is a container with a Default_Iterator aspect. "for E of G.Breadth_First_Search loop" -- The expected type is an iterator with a Default_Iterator aspect. This is two different, unrelated expected types. One could solve that by making this context an "any type" context, and making the checking into Legality Rules, but that means that some expressions would not be allowed ("any type" contexts having restrictions beyond those of other contexts). One could have not allowed the first form, but since that is the only thing people seemed to be asking for, I think that would have been a non-starter. We discussed the question of whether we needed multiple iterators for the "of" form, and the decision was that it was a special shorthand for which additional flexibility -- meaning additional text to write -- would be detremental. I doubt very much that we ever would have allowed multiple expected types - that's evil wherever it appears. >> 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. "Easier to write" almost always is in opposition, because it means using shorthands that cannot easily be deciphered by a human. The "for E of Container loop" is certainly in that category, we only allow it because no one other than implementers need to understand how it works in detail. The way one expects it to work is in fact how it works when read - but if you need to understand the details, it's a disaster. >> > 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. I'm not "refighting" it; you're saying that some nonsense that won't even work is some sort of improvement when it actually would harm understandability of the text. That's an expansion of the functionality, and I'm definitely against any expansion of this idea. One reason is that Ada is gaining too many nice-to-have bells and whistles, to the point that we're losing implementations (after all, there are no Ada 2012 implementations other than GNAT). We can't keep adding cruft, especially when important stuff (parallel operations, for instance) need addressing. Randy.