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!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: class wide iterable (and indexable)
Date: Thu, 03 Jan 2019 08:52:47 +0000
Organization: A noiseless patient Spider
Message-ID: <lyk1jm5di8.fsf@pushface.org>
References: <b5c56fdb-94d0-4930-952c-7754ec5dd729@googlegroups.com>
	<lyo98z558g.fsf@pushface.org>
	<2a6929c5-72fa-4d84-953a-44ea4597ab38@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader01.eternal-september.org;
 posting-host="43a693c318622f50c383d7dba893edfa";
	logging-data="6564"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX18eTNP0CXAXMwTbKaCbhU5o0RnHwHLJ7Ko="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (darwin)
Cancel-Lock: sha1:OGRzK5lxo07Pft1ieEC5nSVUNSI=
	sha1:/t9zgAi+fu2vYS0rK6O48q3+3QM=
Xref: reader01.eternal-september.org comp.lang.ada:55171
Date: 2019-01-03T08:52:47+00:00
List-Id: <comp.lang.ada>

George Shapovalov <gshapovalov@gmail.com> writes:

> Thanks!
> I'll try adding this and see if I can get around that invalid
> interface conversion.
>
> I did see in the Ada.Containers.Vectors code two versions defined,
> however I was not clear on why, especially since both the Ada Gem 10x
> (I forgot now exact number) and Ada Rationale for 2012 seem to only
> provide one, with a Cursor.

ARM A.18.2(34.3)ff[1] has both forms.

> However, from your response (also my general impression while digging
> through the iterables workings) is that this is not a common way to
> provide such code unification. How then one is supposed to go about
> such feature?

You might be interested in Emmanuel's 'traits'-based containers, see
[2], [3].

> On a related note, I was rather surprised that the related types in
> Ada.Containers do not form such a hierarchy. Say both
> Ada.Containers.Vectors and Indefinite_Vectors (and especially now with
> addition of Bounded_Vectors too) all could derive from a common
> ancestor that could be used to implement common functionality and let
> end user chose the desired data storage model..

The Ada 95 Booch Components[4] follow this model. One reason they
weren't taken as a model for Ada.Containers was that the model requires
multiple levels of generic instantiation of child packages: for example,
to make an unbounded map from Unbounded_String to Unbounded_String
requires

   with Ada.Strings.Unbounded;
   with BC.Containers.Maps.Unbounded;
   with BC.Support.Standard_Storage;

   package Configuration_Demo_Support is

      package Abstract_String_Containers is new BC.Containers
        (Item => Ada.Strings.Unbounded.Unbounded_String,
         "=" => Ada.Strings.Unbounded."=");

      package Abstract_String_Maps
      is new Abstract_String_Containers.Maps
        (Key => Ada.Strings.Unbounded.Unbounded_String,
         "=" => Ada.Strings.Unbounded."=");

      function Hash (S : Ada.Strings.Unbounded.Unbounded_String)
        return Natural;

      package String_Maps
      is new Abstract_String_Maps.Unbounded
        (Hash => Hash,
         Buckets => 43,
         Storage => BC.Support.Standard_Storage.Pool);

   end Configuration_Demo_Support;

[1] http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-A-18-2.html#p34.3
[2] https://blog.adacore.com/traits-based-containers
[3] https://github.com/AdaCore/ada-traits-containers
[4] https://sourceforge.net/projects/booch95/