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.140.179.69 with SMTP id z66mr34976455qhz.5.1447750183724; Tue, 17 Nov 2015 00:49:43 -0800 (PST) X-Received: by 10.182.44.169 with SMTP id f9mr364425obm.16.1447750183671; Tue, 17 Nov 2015 00:49:43 -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!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!f78no335526qge.1!news-out.google.com!f6ni5081igq.0!nntp.google.com!i2no4255614igv.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 17 Nov 2015 00:49:43 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2a02:2ab8:224:1:34a2:3544:93ec:86f2; posting-account=6yLzewoAAABoisbSsCJH1SPMc9UrfXBH NNTP-Posting-Host: 2a02:2ab8:224:1:34a2:3544:93ec:86f2 References: <5007b311-5d2e-448c-b8c8-fc2e2d88ea5e@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <64a2a1bd-7519-4d66-bfb6-9b2a1fb1773b@googlegroups.com> Subject: Re: A few questions From: briot.emmanuel@gmail.com Injection-Date: Tue, 17 Nov 2015 08:49:43 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Received-Bytes: 4420 X-Received-Body-CRC: 2482917758 Xref: news.eternal-september.org comp.lang.ada:28414 Date: 2015-11-17T00:49:43-08:00 List-Id: > 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. > 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). 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. > 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. > 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,....) > 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.