Trait based containers

Trait based containers

[Luke A. Guest]

I thought this was being submitted for inclusion into Ada 202X?

What’s happening with this?

Luke 

Re: Trait based containers

[Jere]

On Saturday, May 5, 2018 at 4:43:41 AM UTC-4, Luke A. Guest wrote:
> I thought this was being submitted for inclusion into Ada 202X?
> 
> What’s happening with this?
> 
> Luke

I'm not sure either, but I hope they revert the changes to Map iterators
if they do add it to Ada202x.  I'm not sure why they changed it to iterate
over the keys instead as that seems like the least useful way to iterate
over a map, and you could still access keys via the cursor.  Now the less
useful way is the default.

Re: Trait based containers

[briot.emmanuel]

> I'm not sure either, but I hope they revert the changes to Map iterators
> if they do add it to Ada202x.  I'm not sure why they changed it to iterate
> over the keys instead as that seems like the least useful way to iterate
> over a map, and you could still access keys via the cursor.  Now the less
> useful way is the default.

One of the main principle in the design of that library is that people could
change most of the details. For instance, if you do not like the default
iterator that returns a key, you can easily derive your own that returns an
element instead.

Initially, I had wanted to return a tuple (key, element) directly. This is really
what a cursor is. So instead of doing

    for A of Map loop

you do

   for C in Map.Iterate loop

and you get both key and element.

I prefer to return a key in the "for..of" loop case, because with a map you
can always go from key->element. The opposite might not  be true.

Re: Trait based containers

[Dmitry A. Kazakov]

On 07/05/2018 09:02, briot.emmanuel@gmail.com wrote:

> I prefer to return a key in the "for..of" loop case, because with a map you
> can always go from key->element. The opposite might not  be true.

The main purpose of iteration is not to use keys and thus to avoid to 
the overhead of key-to-element mapping and, possibly, the volatility of 
keys.

Actually in most cases there should no iterators at all but an array 
view of the container instead. Iterators is a necessary evil of 
half-containers like lists, graphs etc.

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

Re: Trait based containers

[briot.emmanuel]

On Saturday, May 5, 2018 at 10:43:41 AM UTC+2, Luke A. Guest wrote:
> I thought this was being submitted for inclusion into Ada 202X?
> What’s happening with this?

I am the original developer for those experimental containers. This was mostly a way
to explore the use of generics in various contexts, and they resulted in a few (I believe
3, though I forgot exactly) new AI submitted to the ARG. Those AI are not about that
library itself, but about various improvements to the language to better support this
kind of generic packages.

I don't think we ever wanted to integrate them into the language. Indeed, Ada already has its own set of containers, so it would be a hard sell to provide a second set of containers.

Instead, the intent was for AdaCore to base its implementation of the standard Ada containers on something like the traits containers, for better code sharing among other things, and maybe also to provide the traits containers as an independent library (I think this is better, as someone else will come with a better implementation/design at some point, so better if it isn't hard-coded in the RM).

Then the SPARK people took interest in those as well, since, as opposed to the Ada containers, they provide a good basis for SPARK-compatible containers. Claire Dross did a huge amount of work to make the containers provable (not proven, this isn't the same thing).

There were quite a few limitations in Ada that made those containers somewhat hard to use for final users. In particular, instantiating the containers is somewhat tricky, especially if you want to control all the details (if you use one of the high-level packages, this is very similar to instantiating Ada's own containers).

Then I left AdaCore...

At this point, I don't think there's anyone working on those containers from the pure Ada library standpoint. I hope that the SPARK people still have an interest in a subset of them, but I must admit I have no internal knowledge of this.

In my new company, we use a lot of similar constructs, and in the process discovered a lot of compiler bugs, mostly related to the use of constructs like expression functions, for..of loops, and others.

It would be nice if there was still interest in that library. The code is all accessible in github, and I believe the license is GPL