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: Tue, 17 Nov 2015 16:09:31 -0600 Organization: JSA Research & Innovation Message-ID: References: <5007b311-5d2e-448c-b8c8-fc2e2d88ea5e@googlegroups.com> <64a2a1bd-7519-4d66-bfb6-9b2a1fb1773b@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1447798173 12119 24.196.82.226 (17 Nov 2015 22:09:33 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 17 Nov 2015 22:09:33 +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:28427 Date: 2015-11-17T16:09:31-06:00 List-Id: wrote in message news:64a2a1bd-7519-4d66-bfb6-9b2a1fb1773b@googlegroups.com... >> 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.) > > I am trying to think of things should have been done, so that perhaps we > can find a > way to fix them in future versions of the language. As this discussion as > shown, there > are lots of very knowledgeable people who are having difficulties with the > current > design and its limitations. If you think this is wasting your time, by all > means feel free > to ignore this thread. I have found it pretty interesting so far. I haven't been ignoring this thread, although I probably should have rather than feeding the trolls. > "there are lots of very knowledgeable people" When it comes to Ada, there are very few knowledgeable people (sadly), so any statement starting with "lots of knowledgeable people" is junk on its face. The only real issue that I've heard from a knowledgeable person is the parameter mode issue (which is always an issue with OOP and Ada, it's not unique here), and there is a very standard approach to mitigate the problem (the Rosen technique). Everything else seems to come from people who want to do C++ or some other language-de-jure in Ada, and that sort of thing has almost always led to making Ada more complex without adding anything of value (anonymous access types, interfaces, etc.) >> 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?? > > I was talking of the Reference_Type (which doesn't need a container in the > public > spec, although it is convenient sometimes to have one to ensure the > lifetime of > the container is greater than that of the reference -- with all the > additional > performance costs). I'm still confused. Where does the value of the Reference_Type come from? It has to come from the call of some function. (More below.) > The Iterator interface is an interface, so of course it doesn't contain > anything. An > actual Iterator implementation is free to store a reference to the > container if it needs > it to implement complex algorithms. An iterator could return a reference > by building > it directly, it doesn't need to go through the Reference function for > this. Building it directly from what? An iterator (in Ada today) is an interface of functions that are called to implement the iteration syntax. Are you proposing to scrap that model? If so, then you have to explain how an iterator type maps to iteration syntax. If not, then you have to describe the functions called and where in that syntax. One way to do that latter would be to create additional iterator interfaces. *That* would work, rather than additional aspects that don't connect to anything. In that case, the function that created the reference type would take a value of the iterator object. That could look something like (names would of course be TBD, "EB" is in honor of you, of course): generic type Cursor; with function Has_Element (Position : Cursor) return Boolean; type Reference_Type is private; package Ada.EB_Iterator_Interfaces is pragma Pure (Iterator_Interfaces); package II is new Ada.Iterator_Interfaces (Cursor, Has_Element); type EB_Forward_Iterator is limited new II.Forward_Iterator with null record; function First (Object : Forward_Iterator) return Cursor is abstract; function Next (Object : Forward_Iterator; Position : Cursor) return Cursor is abstract; function Reference (Object : Forward_Iterator; Position : Cursor) return Reference_Type is abstract; -- Similarly for Reverse_Iterator. end Ada.EB_Iterator_Interfaces; Then one could explain the mapping of iterators to references via calls to Reference, and the relationship with the other iterators. As previously noted, I'm unconvinced this is a good idea, but at least the above would work. Your proposals are leaving out steps that have to be defined in order for it to be a language feature. >> 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??? > > I'll forward you to the discussion you are having with Dmitry. Your notion > of > Index vs Cursor vs Iterators seems to be wrong. No, his notion of index vs. cursor vs. iterators is nonsense. That's typical for him, he uses his own definitions for things, whether or not they have anything to do with the subject at hand. It's something one learns to ignore here (it's pointless to argue with him about it). The only definitions I use are the ones in the Ada Reference Manual. All else is irrelevant to me. >> I'm mapping iteration onto the existing containers. That is >> straightforward >> with the existing description, > > No it is not. Anyone who has already tried to implement their own > iterators > has failed the first time (at AdaCore, but also Simon Wright in the > initial > message here, at courses we have given in various places,....) That's the effect of the lack of good examples more than any problem with the interface. Brad's ACATS tests provide some good examples for users to study, hopefully examples like that will get more play. >> 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.) > > I'll stop this discussion which indeed is leading nowhere. You started by > saying > that for-of is useless, so all the rest is moot from your point of view. I > can > understand where you are coming from. You can't understand where we want > to go. I think I do understand where you want to go, and I really don't think Ada should be going there. Certainly not for sequential programs (I'm more open to change on the parallel side because what we have is way too hard to use). Randy.