From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.8 required=3.0 tests=BAYES_00,PLING_QUERY autolearn=no autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: 2dsa | !2dsa ? Date: Thu, 31 Dec 2020 17:43:39 -0600 Organization: JSA Research & Innovation Message-ID: References: <2fa5a097-a0a6-4614-b990-ee70b89ab470n@googlegroups.com> <578126cd-507b-4e6b-8c08-31a115773bd2n@googlegroups.com> <30f2c0d8-58c2-4ca9-bfd6-2aa38309d27cn@googlegroups.com> Injection-Date: Thu, 31 Dec 2020 23:43:40 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="32653"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:60998 List-Id: "Dmitry A. Kazakov" wrote in message news:rsfg32$1etf$1@gioia.aioe.org... > On 2020-12-29 00:41, Randy Brukardt wrote: >> "Rod Kay" wrote in message >> news:30f2c0d8-58c2-4ca9-bfd6-2aa38309d27cn@googlegroups.com... >>> Apologies for the prior empty post. >>> >>> Is it likely that the ARG might address the aformentioned issues ? >> >> As of now, it doesn't appear that there would be any point. Annex E is an >> optional annex, and so far as we're aware, no compiler vendor has any >> plans >> for increasing support for that annex. So the ARG could change the annex >> but >> it seems unlikely that any changes would make it into implementations. >> (We've been told not to expect even the implementation of bugs fixes >> included in Ada 202x, even from the vendor that originally requested the >> bug >> fixes.) > > Why there should be any vendor support in the first place? Why not to > redefine it as a set of abstract tagged types allowing custom user > implementations like storage pools and streams do? Marshalling/unmarshalling surely require vendor support, and there has to be a standard interface for the marshalling stuff to talk to. That to me was always the value of Annex E. My understanding is that there is not much interest in doing any work at all, even to correct the mistakes in the existing definitions. In any case, Storage_Pools and Streams are some of the most expensive features of Ada to support. That's not a model for "lightweight" support of anything. My advice would be to talk to your vendor if you feel strongly about this sort of support. Randy.