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!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!reality.xs3.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 16:15:01 -0600 Organization: JSA Research & Innovation Message-ID: References: <1dolqizyi8gxi.t3173bhifuu1.dlg@40tude.net> <1705bpj6jrld0.1lc44o5yo6bj7$.dlg@40tude.net> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1447452902 24960 24.196.82.226 (13 Nov 2015 22:15:02 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 13 Nov 2015 22:15:02 +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:28362 Date: 2015-11-13T16:15:01-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:1705bpj6jrld0.1lc44o5yo6bj7$.dlg@40tude.net... > On Fri, 13 Nov 2015 11:52:29 -0600, Randy Brukardt wrote: ... >> And if you did that, there is >> no problem implementing this in the existing Ada, even as you suggest. > > I am not sure about that. I am. :-) You'd probably keep some state in the iterator object (some access to the file, at a minimum, possibly a buffer). The "cursor" would be the character. Each call to Next would put the following character into the "cursor". Easy-peasy. :-) Thinking of an iterator "cursor" as having to be some sort of index obscures the real possibilities of the interface. >>> Operation Read provides an iterateable container-view of Text_File. >>> There >>> cannot be any index, because the "buffer" will contain just single line. >> >> A "cursor" is not necessarily an array index, as I pointed out earlier in >> this thread. > > Array does not contain "cursors." Cursor is an evil idea, but that is > unrelated to the issue of iteration over a general set. We're not talking about arrays, we're talking about iteration. And for this purpose, "cursor" could just as well be called "blob". It's a type parameter to the interface, nothing more. One might give it additional semantics for some particular implementation, but that's not inherent in the model. >>>> An array is surely >>>> a container, and we got along just fine for 30 years without being able >>>> to iterate elements of arrays. >>> >>> Not every container is an array. There are lots of containers which >>> semantically have no index. >> >> Then provide an iterator implementation where the cursor is an access to >> the >> element. > > Why do I need extra data types, bad types as they involve pointers? An iterator is an extra data type. And you surely don't need to involve pointers, if copying the element is OK. If you want to modify the element in place, then some sort of pointer is always required (outside of the built-in array type). ... ... >> You are giving more properties than necessary to an iteration cursor >> (which >> is what we are talking about). There is absolutely no problem with it >> providing sequential one-time access. You have to program it that way, of >> course, but it's not hard to do (see the implementation in the ACATS, for >> one example). > > Maybe yes, maybe no. But cursor is neither index nor element. Cursor is > same as a pointer. Definitely not, in the iterator interface. It is anything you want it to be. Surely, for discrete unmodifiable values, it's better that the "cursor" be directly that value. (The read from a file example, the prime numbers example, and the OPs example all have this property.) "Cursor" is just the name of the type in the generic interface. Just because it has that name (and is commonly used as an index), doesn't mean that it always has to be used that way. ... >> That's the Bag arrgument again. I think that particular data structure is >> a >> fraud, because it cannot be created in practice -- plus you have to have >> some sort of access to the elements, so you end up with a cursor of some >> sort anyway. > > No way. The bag is a set that only supports insertion and iteration. > Nothing more. It is very useful, e.g. to hold strong references to > allocated data. References are thrown into a bag. At some point the bag is > iterated and all references invalidated releasing resources. Your description points out the problem: it's "a set", at which point a set implementation is appropriate. And the implementation is identical to any other set, so there is almost no value to having a separate bag implementation (it provides no performance improvements over an ordered set, for instance). Whether its useful or not is irrelevant -- it is indistiguishable from any other set (the extra operations having no effect or overhead if not used). So there is no real value to having a separate Bag abstraction. Randy.