Creation from array and replication of vectors.

[Blady-Com]

Proposal to complete Ada.Containers.Vectors with the following self explained definitions:

   type Elements_Array is array (Index_Type range <>) of Element_Type;
   function To_Vector (Elements : Elements_Array) return Vector;
   function To_Array (Container : Vector) return Elements_Array;

   function "*" (Left : Natural; Right : Vector) return Vector;

[ARG-Editor]

This wasn't done originally as we wanted the definite and indefinite containers to have the same set of operations. This set of operations is clearly impossible for an indefinite container (you cannot have indefinite components). Using operations like these would make it impossible to later change to an indefinite container from a definite one.

Whether or not that intention should be further abandoned is probably worthwhile for discussion.

[ARG-Editor]

What is the self explained definition for:

function "*" (Left : Natural; Right : Vector) return Vector;

??

The Element_Type of a vector can be any sort of non-limited type, and often is another container type. It doesn't make sense to multiply a record type times 2. So it can't mean an element-by-element multiply. I don't know of any other meaning for "*".

[jprosen]

I think it means Right appended Left times

[sttaft]

I presume these are intended to be similar to the "*" operators in the various Strings packages:

function "" (Left : in Natural; Right : in Character) return* String;

function "" (Left : in Natural; Right : in String) return* String; These functions replicate a character or string a specified number of times.

-Tuck

On Thu, Feb 15, 2024 at 2:40 AM Jean-Pierre Rosen @.***> wrote:

I think it means Right appended Left times

— Reply to this email directly, view it on GitHub https://github.com/Ada-Rapporteur-Group/User-Community-Input/issues/77#issuecomment-1945515200, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANZ4FJDI4NTRTA6KFRFW4TYTW3X3AVCNFSM6AAAAABBZMPVECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBVGUYTKMRQGA . You are receiving this because you are subscribed to this thread.Message ID: @.*** .com>

[Blady-Com]

I think it means Right appended Left times

Yes that's it.

[ARG-Editor]

In addition to my previous comment, it should be pointed out that it is easy to write the proposed To_Vector function as an aggregate of the vector type: [for E of Elements] (Elements being the name of the input array) And similarly for To_Array: [for E of Container] These aggregates have the advantage that they work with any appropriate array type, they don't need to use a type declared in the container package. And arguably, they are more understandable.

[ARG-Editor]

The ARG considered this Issue at meeting #63C. Given that writing aggregates is available and probably has similar performance to the proposed functions, there was no support for adding these functions.

It was pointed out that for small numbers of N, aggregates or uses of "&" is easy and more understandable than a function with a name that does not immediately suggest a particular operation. Tucker also notes that the following expression will have the exact function of the proposed "*" operation: [for I in 1 .. Right => Left]'Reduce("&", []) While this is not the most understandable expression (indeed, I think it should be exhibit A in the obfuscated Ada museum), it does demonstrate that the existing facilities of Ada are sufficient to create this operation yourself. We also did not think this operation would be common enough for the performance to be a major concern.

For all of these reasons, the ARG voted 12-0-0 for No Action for this issue, and directed the editor to write this explanation and close the issue.

[Blady-Com]

Thanks all of you for your answers. I appreciate all proposed alternatives, there actually are valuable.

I would like advocate: Despite proposed alternatives, generally speaking, I strongly believe that offering such subprograms participate to help adoption of Ada. One success reason of other popular languages is the large range of offered API even the simpler ones. New comers will appreciate to find immediately in their language kitchen the right tool at their finger tips to build their programs whatever an inline alternative exists.

[ARG-Editor]

Speaking only for myself (not in any official capacity):

I don't think that people who need an API for every possible need are actually candidates to adopt Ada in the first place. Ada is about correctness and contracts and compile-time checks, and APIs tend to make those things harder. Moreover, rarely used APIs cause code bloat, offer places for security holes, and make Ada harder to implement and maintain (maybe only by a tiny amount, but every additional has that effect). We don't have enough Ada implementations as it is.

I doubt anyone really knows what (if anything) would actually increase Ada adoption. It certainly isn't going to be the presence or absence of a To_Array function that doesn't work with the user's array type anyway (and makes the different kinds of containers more different than necessary). Saying something would increase Ada adoption is a lazy argument used when someone doesn't have any more actual facts to offer.

Finally, even if something would actually increase Ada's adoption today, it probably won't by the time it gets through standardization (3-10 years from now). What people are interested in changes rapidly. Moreover, if the promise of AI searching actually works out, the only thing important for a programming language is that there is a concise, understandable way to do something, not particularly what it is. AI should be able to retrieve the way to do something; it won't be necessary for it to be obvious. Indeed, duplicating functionality as these subprograms would do would be more likely to confuse AI rather than help (the aggregate would certainly be preferred to convert something other than a complete array; the ability to include filters to select elements makes it a much more powerful notation than a simple function call).

            Randy.