On 2022-09-02 13:20, Emmanuel Briot wrote:
>
> 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);

Where is that? All I saw in my quick look were Maps, Maps.Generics, and Maps.Impl.

--
Jeff Carter
"Apple juice and Darvon is fantastic together."
Play It Again, Sam
127

"amo...@unizar.es" <amosteo@unizar.es> wrote in message
news:672e9bc6-1e53-42cb-a339-9230ab949de9n@googlegroups.com...
On Thursday, September 1, 2022 at 11:33:47 PM UTC+2, Jeffrey R.Carter wrote:
> On 2022-09-01 20:54, Emmanuel Briot wrote:

>> As presented, this seems very over complicated. Elements and
>> Definite_Elements
>> add no value, and this is just a complex way of writing

>Going in a tangent, and I guess you know perfectly well, but this is caused
>by the
>painful duplication of code that Ada pushes you to by not having a native
>way to
>abstract storage of definite vs indefinite types.

This is premature optimization at it's worst.

> So the provider of a generic library very soon faces this conundrum about
> duplicating most interfaces, if not implementations, or resort to
> non-trivial
> generics, or accept an unnecessary penalty for definite types, or push to
> the client the definite storage matter.

There is no penalty in a code sharing implementation like Janus/Ada: the
implementation of definite types is essentially the same as you would write
by hand for an indefinite type. In most cases, all one needs is an
indefinite generic.

(The plan for Janus/Ada was always to use post-compilation optimization to
reduce the overhead of generics, but admittedly, that part never got built.
If I had infinite time...)

Assuming otherwise is certainly premature optimization.

> There's simply no satisfying solution here [that I know of]. The
> duplication of
> every standard container to have both [in]definite variants is a strong
> indictment.

The original expectation for the containers was that there would be many
variants of each container, because the needs for memory management, task
management, and persistence differ between applications: there is no
one-size fits all solution.

But I agree on one point: the "basic" container is unncessary; one should
either use the indefinite or bounded container (depending on your memory
management needs, either fully fixed or fully heap-based) -- stopping in the
middle makes little sense.

Randy.

"Emmanuel Briot" <briot.emmanuel@gmail.com> wrote in message
news:b678b499-0cb1-4c64-a88f-cfa9a79893e6n@googlegroups.com...

>These packages are mostly implementation details. They are used to build
>high-level
>packages similar to the Ada containers, except with much better code reuse,
>more
> efficient, and SPARK-provable.

(Wading in where I should probably not tread... :-)

But they violate the #1 principle of the Ada.Containers: ease of use. One
principle that we insisted on was that a single instantiation was the
maximum we would use, because we did not want people moving from arrays to
containers to have to replace one declaration with a half page of magic
incantations. (This is the reason that there is no container interface, for
one consequence, and certainly no signature packages.)

In general, people either undertand and like signature packages, or really
do not understand them and just use them when insisted on. The standard
containers in Ada needed to be usable by the maximum number of users, and
insisting on bells and whistles that many don't understand does not help.

Randy.

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:teso01$16gg$1@gioia.aioe.org...
> On 2022-09-02 12:41, Jeffrey R.Carter wrote:
>
>> The only indefinite data structure that is needed seems to be holders.
>
> The language should support and encourage design that does not rely on
> memory pools.
>
> In my view one of major advantages of Ada is that indefinite objects can
> be handled without resorting to hidden or explicit pointers to pools.

But they're implemented with some sort of hidden allocation. (GNAT uses a
"secondary stack", whatever that is, but that is just a restricted form of
pool). Janus/Ada uses built-in pools with cleanup for all such things to
simplify the interface (the code for allocations and stand-alone objects is
mostly shared, both within the compiler and at runtime).

Randy.

"Emmanuel Briot" <briot.emmanuel@gmail.com> wrote in message
news:bf352372-632c-45c1-b691-758756e87541n@googlegroups.com...
....
> And Ada doesn't support default values for the formal parameters of
> generics (another annoying limitation !)

Ada *DOES* support default values for formal parameters of generics. At
least the most used kinds of parameters, including subprograms and types
(the latter added in Ada 2022). Whether GNAT (or your other favorite
compiler) supports formal type defaults yet is a different question.

Randy.

On 2022-09-03 02:12, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:teso01$16gg$1@gioia.aioe.org...
>> On 2022-09-02 12:41, Jeffrey R.Carter wrote:
>>
>>> The only indefinite data structure that is needed seems to be holders.
>>
>> The language should support and encourage design that does not rely on
>> memory pools.
>>
>> In my view one of major advantages of Ada is that indefinite objects can
>> be handled without resorting to hidden or explicit pointers to pools.
>
> But they're implemented with some sort of hidden allocation. (GNAT uses a
> "secondary stack", whatever that is, but that is just a restricted form of
> pool). Janus/Ada uses built-in pools with cleanup for all such things to
> simplify the interface (the code for allocations and stand-alone objects is
> mostly shared, both within the compiler and at runtime).

For a programmer that does not matter. The problem with pools is
locking, non-determinism, issues with protected actions. If secondary or
primary stack is the program stack, nobody really cares.

BTW, merely doing pool tracing/bookkeeping becomes a sheer nightmare if
you cannot return a string from a function.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 2022-09-03 02:07, Randy Brukardt wrote:
>
> One
> principle that we insisted on was that a single instantiation was the
> maximum we would use

Except for queues

--
Jeff Carter
"In our experiments, the [Ada] compile[r] was able to find not
just typographical errors, but also conceptual errors in the
development of the code."
Scott and Bagheri
161

"Randy Brukardt" <randy@rrsoftware.com> writes:

> But they violate the #1 principle of the Ada.Containers: ease of
> use. One principle that we insisted on was that a single instantiation
> was the maximum we would use

And this was one reason that I didn't put up any arguments at Ada Europe
2002 for the Ada 95 Booch Components to form a basis for Ada.Containers
- you'd need 3 instantiations, one after the other.

-- A company's Fleet holds a number of Cars.

with BC.Containers.Collections.Bounded;
with Cars;
package My_Fleet is

use type Cars.Car;

package Abstract_Car_Containers
is new BC.Containers (Cars.Car);

package Abstract_Car_Collections
is new Abstract_Car_Containers.Collections;

package Fleets
is new Abstract_Car_Collections.Bounded (Maximum_Size => 30);

The_Fleet : Fleets.Collection;

end My_Fleet;

The other was a lack of consistency in the implementation (Length?
Size?).

Jeff Carter:
> Where is that? All I saw in my quick look were Maps, Maps.Generics, and Maps.Impl.

Simon Wright:
> And this was one reason that I didn't put up any arguments at Ada Europe
> 2002 for the Ada 95 Booch Components to form a basis for Ada.Containers
> - you'd need 3 instantiations, one after the other.

I definitely see the same issue. The way my library is trying to workaround that is as follows:
Those instantiations are only needed for people who want/need to control every aspects of their containers, for instance
how elements are stored, how/when memory is allocated, what is the growth strategy for vectors, and so on.
Most users should not have to care about that in practice. So we use code generation at compile time to generate
high-level packages similar to the Ada containers, with a limited set of formal parameters (in src/generated, to be
more specific). We can generate bounded/unbounded versions, definite/indefinite versions, and any combination of
those.
One of the intentions of the library, initially, had been the implementation of the Ada containers and SPARK containers
in GNAT, as a way to share as much code as possible between the two.

Randy Brukardt:
> Assuming otherwise is certainly premature optimization.

I am quoting a bit out of context, though I believe it is close enough. Designers of containers must care about performance
from the get-go. Otherwise, people might just as well use a list for everything and just traverse the list all the time. We all
know this would be way too inefficient, of course, which is why there are various sorts of containers.
Anyone who has actually written performance-sensitive code knows that memory allocations is definitely something to watch
out for, and the library design should definitely take that into account.

Jeff Carter:
> The only indefinite data structure that is needed seems to be holders

Although it is certainly true that using holders works, it is not applicable when designing a containers library that intends to be
mostly compatible with Ada containers. The latter have chosen, long ago and before Holder was a thing, to have definite and
indefinite versions. The main benefit to this approach is that users still retrieve directly the type they are interested in (e.g. String)
rather than a holder-to-string.
I must admit I have very limited experience with Holders, which I have never used in production code (nor, apparently, have my
colleagues and ex-colleagues).

Randy Brukardt:
> Ada *DOES* support default values for formal parameters of generics

Hey, I just discovered that, thanks Randy ! For people who also did not know that:

generic
type Item_Count is range <> or use Natural;
package Gen is

It is supported by GNAT's newer versions (I don't know when it was implemented though)

On 2022-09-05 08:56, Emmanuel Briot wrote:

> Although it is certainly true that using holders works, it is not applicable when designing a containers library that intends to be
> mostly compatible with Ada containers.

Right. Holder requires finalization and finalization means language
prescribed finalization lists which is highly undesirable in many cases.

> The main benefit to this approach is that users still retrieve directly the type they are interested in (e.g. String)
> rather than a holder-to-string.

And that the container designer has control over the pool where the
items get actually allocated.

> I must admit I have very limited experience with Holders, which I have never used in production code (nor, apparently, have my
> colleagues and ex-colleagues).

I have been using the idea for a long time, since Ada 95 before the
standard library had them. In my experience holders multiply the number
of container variants:

1. Definite elements
2. Indefinite elements
+
3. Holder elements in the interface (and maybe implementation)

The third gets a holder package as a formal parameter or, alternatively,
is a child of a holder package (for performance reasons). The container
interface has direct operations in terms of the Element_Type as well as
in terms of the holder type.

Sometimes the holder variant is actually the indefinite one that
promotes holders only in its interface.

P.S. In my opinion helper types/package is an evil of far greater scale
than any premature optimization!

The programmers doing the latter at least try to understand the code
they write.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On Saturday, September 3, 2022 at 2:01:32 AM UTC+2, Randy Brukardt wrote:
> "amo...@unizar.es" <amo...@unizar.es> wrote in message
> news:672e9bc6-1e53-42cb...@googlegroups.com...
> On Thursday, September 1, 2022 at 11:33:47 PM UTC+2, Jeffrey R.Carter wrote:
> > On 2022-09-01 20:54, Emmanuel Briot wrote:
>
> >> As presented, this seems very over complicated. Elements and
> >> Definite_Elements
> >> add no value, and this is just a complex way of writing
>
> >Going in a tangent, and I guess you know perfectly well, but this is caused
> >by the
> >painful duplication of code that Ada pushes you to by not having a native
> >way to
> >abstract storage of definite vs indefinite types.

> This is premature optimization at it's worst.

Just because the language doesn't offer a way to do it. Otherwise I wouldn't need to care.

> > So the provider of a generic library very soon faces this conundrum about
> > duplicating most interfaces, if not implementations, or resort to
> > non-trivial
> > generics, or accept an unnecessary penalty for definite types, or push to
> > the client the definite storage matter.
> There is no penalty in a code sharing implementation like Janus/Ada: the
> implementation of definite types is essentially the same as you would write
> by hand for an indefinite type. In most cases, all one needs is an
> indefinite generic.

Well, that sounds neat for Janus/Ada, but is a different issue to clients having to wrap their indefinite types prior to instantiation, and suffer the unwrapping throughout the code.

> (The plan for Janus/Ada was always to use post-compilation optimization to
> reduce the overhead of generics, but admittedly, that part never got built.
> If I had infinite time...)
>
> Assuming otherwise is certainly premature optimization.

I'm of the opinion that it goes beyond just premature optimization, in the terrain of readability/maintainability by causing boilerplate, and when generics specializations do become necessary, by causing code duplication.

> > There's simply no satisfying solution here [that I know of]. The
> > duplication of
> > every standard container to have both [in]definite variants is a strong
> > indictment.
> The original expectation for the containers was that there would be many
> variants of each container, because the needs for memory management, task
> management, and persistence differ between applications: there is no
> one-size fits all solution.
>
> But I agree on one point: the "basic" container is unncessary; one should
> either use the indefinite or bounded container (depending on your memory
> management needs, either fully fixed or fully heap-based) -- stopping in the
> middle makes little sense.

That makes sense, right.

>
> Randy.

On Monday, September 5, 2022 at 10:53:21 AM UTC+2, amo...@unizar.es wrote:
> On Saturday, September 3, 2022 at 2:01:32 AM UTC+2, Randy Brukardt wrote:

> Well, that sounds neat for Janus/Ada, but is a different issue to clients having to wrap their indefinite types prior to instantiation, and suffer the unwrapping throughout the code.

Drats, I was here obviously thinking about the contrary case where only the definite container exists...

On 2022-09-05 08:56, Emmanuel Briot wrote:
>
> I definitely see the same issue. The way my library is trying to workaround that is as follows:
> Those instantiations are only needed for people who want/need to control every aspects of their containers, for instance
> how elements are stored, how/when memory is allocated, what is the growth strategy for vectors, and so on.
> Most users should not have to care about that in practice. So we use code generation at compile time to generate
> high-level packages similar to the Ada containers, with a limited set of formal parameters (in src/generated, to be
> more specific). We can generate bounded/unbounded versions, definite/indefinite versions, and any combination of
> those.

This seems backwards. The user should encounter the forms most likely to be used
first; if part of the packages are in a subdirectory, those should be the ones
less likely for the typical user to use.

> Although it is certainly true that using holders works, it is not applicable when designing a containers library that intends to be
> mostly compatible with Ada containers. The latter have chosen, long ago and before Holder was a thing, to have definite and
> indefinite versions. The main benefit to this approach is that users still retrieve directly the type they are interested in (e.g. String)
> rather than a holder-to-string.

Before Ada.Containers existed, I commonly used definite data structures from the
PragmARCs with Unbounded_String, which is partly a specialized holder for String
(and partly a specialized Vector for Positive/Character). Generalizing from this
led to implementing a Holder pkg.

When I said a holder is the only indefinite pkg that is needed, I meant to imply
that other indefinite structures would be implemented using the definite form +
holder.

--
Jeff Carter
“Bug rates in C++ are running higher even than C ...”
Stephen F. Zeigler
216

"Jeffrey R.Carter" <spam.jrcarter.not@spam.acm.org.not> wrote in message
news:tev515$2rbj5$1@dont-email.me...
> On 2022-09-03 02:07, Randy Brukardt wrote:
>>
>> One
>> principle that we insisted on was that a single instantiation was the
>> maximum we would use
>
> Except for queues

Right, and one consequence of that is that the queues aren't used much. (Not
sure if they would be used much in any case, they're definitely a
specialized need compared to a map.)

Randy.

"Emmanuel Briot" <briot.emmanuel@gmail.com> wrote in message
news:458444ed-e384-4663-896c-bb38dae3c5cbn@googlegroups.com...
....
> Randy Brukardt:
>> Assuming otherwise is certainly premature optimization.
>
> I am quoting a bit out of context, though I believe it is close enough.
> Designers of containers must care about performance
> from the get-go. Otherwise, people might just as well use a list for
> everything and just traverse the list all the time. We all
> know this would be way too inefficient, of course, which is why there
> are various sorts of containers. Anyone who has actually written
> performance-sensitive code knows that memory allocations is definitely
> something to watch out for, and the library design should definitely take
> that into account.

Definitely out of context. If you have code which is truly performance
sensitive, then it cannot also be portable Ada code. That's because of the
wide variety of implementation techniques, especially for generics. (For
Janus/Ada, if you have critical performance needs, you have to avoid the use
of generics in those critical paths -- sharing overhead is non-zero.)

I agree that the design of the containers matters (which is why the we made
the sets of operations for the various containers as close as possible, so
switching containers is relatively easy). But the indefinite/definite thing
is premature optimization - it makes little difference for a Janus/Ada
generic, at least in the absence of the full-program optimizer (that we
never built). If your code isn't intended to be portable Ada code, then
*maybe* it makes sense to worry about such things. But the expectation was
always that containers would be useful in cases where the performance is
*not* critical - one probably should use a custom data structure for
performance critical things. (But most things aren't really performance
critical in reality.)

Randy.