From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: * X-Spam-Status: No, score=1.6 required=3.0 tests=BAYES_00,PDS_FROM_2_EMAILS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Received: by 2002:a37:a843:0:b0:6c3:3902:a346 with SMTP id r64-20020a37a843000000b006c33902a346mr467064qke.538.1662107712275; Fri, 02 Sep 2022 01:35:12 -0700 (PDT) X-Received: by 2002:a81:6309:0:b0:323:6fd9:8f36 with SMTP id x9-20020a816309000000b003236fd98f36mr25285762ywb.96.1662107711991; Fri, 02 Sep 2022 01:35:11 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!border-1.nntp.ord.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 2 Sep 2022 01:35:11 -0700 (PDT) In-Reply-To: Injection-Info: google-groups.googlegroups.com; posting-host=155.210.248.194; posting-account=SuyozQoAAADXnDELfODTBs7QDv_fdf87 NNTP-Posting-Host: 155.210.248.194 References: <67b32db0-c4db-466c-ac13-e597e008c762n@googlegroups.com> <401d6f59-2c28-4dd5-9fa6-fccf33b6d645n@googlegroups.com> <12cc33b1-2c39-4057-8a03-623064b06e8en@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <672e9bc6-1e53-42cb-a339-9230ab949de9n@googlegroups.com> Subject: Re: Calling inherited primitive operations in Ada From: "amo...@unizar.es" Injection-Date: Fri, 02 Sep 2022 08:35:12 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:64265 List-Id: 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:=20 > As presented, this seems very over complicated. Elements and Definite_Ele= ments=20 > add no value, and this is just a complex way of writing=20 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. So the prov= ider 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's simply no satisfying solution here [t= hat I know of]. The duplication of every standard container to have both [i= n]definite variants is a strong indictment.=20 I can understand the desire to have full control of allocation and object s= izes, but that there's not a language way to work around this duplication, = with appropriate restrictions to go with it, is... bothersome. Not making a= dig at the ARG, which I understand is overstretched as it is.=20 There was a proposal circulating some time ago that seemed promising, that = I can't quickly find. Something like type Blah is record Dont_care_if_in_heap: new Whatever_Definiteness; -- Would apply to inde= finite types or formals end record; I don't think it made into https://github.com/AdaCore/ada-spark-rfcs/ or ht= tps://github.com/Ada-Rapporteur-Group/User-Community-Input/issues or I can'= t find it.