Re: [ANN] List_Image v0.2.0

[briot.emmanuel@gmail.com]

> List_Image is a small helper to print the content of Ada predefined containers, available here : https://github.com/LionelDraghi/List_Image


Nice !

And well documented :-)

When I started on the traits containers, I was hoping to create a library of common signature packages that could be reused and built upon in various libraries. Perhaps we could get started on that.

I must admit I never thought of the `Image_Style` traits, but they definitely fit very well.

Some comments on the code:

  * EOL should be defined different when on Windows. I used to test whether the GNAT.OS_Lib.Directory_Separator is '\', perhaps there's a better way nowadays. For sure, a "Is_Windows" constant would be useful somewhere.

     EOL : constant String := (if Is_Windows then ASCII.CR & ASCII.LF else ASCII.LF);

  * Cursors_SIgnature is what I was calling a Forward_Cursor in the traits containers. So there's some code sharing to be done here :-) However, the profile of Has_Element and Next, in my case, was also receiving the container as a parameter, so that they could be compatible with the formal containers distributed with GNAT, and used in SPARK. It is easy to ignore that extra parameter for the standard Ada containers, but not possible to invent it if not given.
For some reason, I was also passing No_Element and "=", but without looking at the code in more details, my first thought now is that these should not be there, so your approach is lighter and likely better.

  * It would be more efficient to use GNATCOLL.Strings instead of Unbounded_Strings (a lot more effort was done for performance there), but then it adds a dependency on a third party library. GNATCOLL.Strings is also using some kind of traits-based approach (and I have a version locally that uses traits to decide whether to use atomic counters, non-atomic counters, or no counter at all (and thus no copy-on-write).   Again in the spirit of sharing a signature-based library somewhere

    By the way, using  'Tmp := Tmp & "...";' is inefficient compared to 'Append (Tmp, "...")` so I would recommend the latter.


   * I see you finally gave up on using the iterable as formal parameters. I also had very limited success with that. As a result, the generic algorithms have to be written using explicit cursors, but since they are reused easily, that's not such an issue.