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.36.83.11 with SMTP id n11mr26456099itb.48.1517472306832; Thu, 01 Feb 2018 00:05:06 -0800 (PST) X-Received: by 10.157.3.6 with SMTP id 6mr454581otv.3.1517472306456; Thu, 01 Feb 2018 00:05:06 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.unit0.net!peer01.am4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!w142no144121ita.0!news-out.google.com!s63ni210itb.0!nntp.google.com!w142no144120ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 1 Feb 2018 00:05:06 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=176.130.29.212; posting-account=6yLzewoAAABoisbSsCJH1SPMc9UrfXBH NNTP-Posting-Host: 176.130.29.212 References: <575826a1-c983-49aa-95e2-54048f6b7b5b@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <5e231964-53df-4d4c-b0e0-782bcb0746a6@googlegroups.com> Subject: Re: [ANN] List_Image v0.2.0 From: briot.emmanuel@gmail.com Injection-Date: Thu, 01 Feb 2018 08:05:06 +0000 Content-Type: text/plain; charset="UTF-8" X-Received-Body-CRC: 2368174421 X-Received-Bytes: 4086 Xref: reader02.eternal-september.org comp.lang.ada:50238 Date: 2018-02-01T00:05:06-08:00 List-Id: > I defaulted EOL to Windows CRLF, because it's seems to work well on my Linux box also. Isn't this because you are printing with Ada.Text_IO, which takes care of normalizing end-of-line terminators ? It might not work when using streams, for instance. > But note that it can be overridden when instantiating Cursors. Sure, but I think you should aim at having a package that works on multiple platforms, so that users do not have to care about that notion themselves. > For Next and Has_Element, changing the profile would prevent the easy instantiation > with Ada containers. If we want the same simplicity with another container collection, > I suppose there's no way out, we need to provide more versions of this Cursor generic One possible approach is to have two signature packages: one that takes the same profile you do (i.e. Has_Element only receives the cursor), and one for which Has_Element also receives the container. Algorithms would expect the second one, but the first one would provide an instance of the second. As in: generic type Container is private; type Cursor is private; with function Has_Element (Self : Container; C : Cursor) return Boolean; package Forward_Cursors is end Forward_Cursors; generic type Container is private; type Cursor is private; with function Has_Element (C : Cursor) return Boolean; package Ada_Forward_Cursors is function Has_Element (Self : Container; C : Cursor) return Boolean is (Has_Element (C)); package FC is new Forward_Cursors (Container, Cursor, Has_Element); end Ada_Forward_Cursors; For standard containers, you instantiate Ada_Forward_Cursors, but pass the "FC" package to the algorithms. The main drawback is the need for finding good names, in my experience. But that makes your algorithms compatible with SPARK and its formal containers. My own experience when writing containers is that in effect it is much easier to receive the container as a parameter to Has_Element (avoids the need for unchecked_access to the container in the cursor, as done for the Ada containers). > I remembered that for some reason you decided to provide your own > Ada.Containers.Count_Type in your Container, so I choose to stick to > First/Next/Has_Element instead of First/Next/Length. Length is a notion that might be hard to compute for some containers, so indeed better not to rely on it if you can. I believe the reason I was using my own Count_Type was for compatibility with SPARK and making it easier to prove things. > Yes, I prefer to avoid non standard dependencies. GNATCOLL is standard :-) Just kidding.