From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,FREEMAIL_FROM, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Received: by 2002:a05:622a:13ca:b0:343:129:8894 with SMTP id p10-20020a05622a13ca00b0034301298894mr26908117qtk.253.1662117639245; Fri, 02 Sep 2022 04:20:39 -0700 (PDT) X-Received: by 2002:a81:7cc3:0:b0:336:e83b:51fd with SMTP id x186-20020a817cc3000000b00336e83b51fdmr27600700ywc.457.1662117639040; Fri, 02 Sep 2022 04:20:39 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 2 Sep 2022 04:20:38 -0700 (PDT) In-Reply-To: Injection-Info: google-groups.googlegroups.com; posting-host=2a01:e0a:810:89e0:2863:e1f:40fd:f3da; posting-account=6yLzewoAAABoisbSsCJH1SPMc9UrfXBH NNTP-Posting-Host: 2a01:e0a:810:89e0:2863:e1f:40fd:f3da References: <67b32db0-c4db-466c-ac13-e597e008c762n@googlegroups.com> <401d6f59-2c28-4dd5-9fa6-fccf33b6d645n@googlegroups.com> <12cc33b1-2c39-4057-8a03-623064b06e8en@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Calling inherited primitive operations in Ada From: Emmanuel Briot Injection-Date: Fri, 02 Sep 2022 11:20:39 +0000 Content-Type: text/plain; charset="UTF-8" X-Received-Bytes: 3842 Xref: reader01.eternal-september.org comp.lang.ada:64272 List-Id: > not user friendly. There appears to be extensive HTML documentation, but it can > only be viewed as HTML source in Github, which is not easy to read, so I didn't. Those are generated from the .rst files in docs_src/ > typical user, for whom using a hashed-map abstraction should be as simple as > > function Hash (Key : in Identifier) return Hash_Value; > package Maps is new Lib.Maps > (Identifier => Identifier, Associated_Value => Associated_Value); Maps are created as package Maps0 is new GAL.Maps.Def_Def_Unbounded (Integer, Element_Type => Integer, Hash => Test_Support.Hash, Container_Base_Type => GAL.Controlled_Base); The only addition here is `Container_Base_Type`, and that's because the library is probable with SPARK, and the latter doesn't support controlled types. And Ada doesn't support default values for the formal parameters of generics (another annoying limitation !) > I was not willing to spend more than about 15 minutes trying to understand this, > so I may be missing something. Fair enough. The library is really a set of experiments, mostly successful, and I think it might have been used for the implementation of the current SPARK containers in GNAT, though I am not positive there. I did look at the pragmARC components, and there you indeed chose to have a large number of similar-looking packages and code duplication. I guess we'll have just to agree to disagree on the design approach there. But of course, users having choices is what makes an ecosystem interesting. What I was really going after are graphs and their algorithms. In particular, I want those algorithms to work on any graph data structure provided it has a number of primitive operations. In fact, the algorithm could also work when the graph is kind of implicit in the code, even if we do not have an actual Graph object. And those this, you need generics. A similar approach is what Rust uses all over the place with its traits, or what C++ Boost library uses for its graphs, too.