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.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.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: Proposal: Auto-allocation of Indefinite Objects Date: Sat, 22 Aug 2020 23:48:13 -0500 Organization: JSA Research & Innovation Message-ID: References: <94a54092-a56f-4a99-aaec-08dd611c8fd8@googlegroups.com> <8a502b6c-4609-4cd8-b292-5797fe6421e1n@googlegroups.com> Injection-Date: Sun, 23 Aug 2020 04:48:15 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="11109"; 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: reader01.eternal-september.org comp.lang.ada:59783 List-Id: "Dmitry A. Kazakov" wrote in message news:rhnqjf$bga$2@gioia.aioe.org... > On 21/08/2020 01:30, Randy Brukardt wrote: ... >> There's no reason that a compiler couldn't "build-in" a simple bounded >> vector container as the basic building block. > > That simply replaces the word "array" with four words "simple bounded > vector container." The construct is still there and it is still built-in. > The syntax and usability are drastically worse, though. ??? The syntax of use is the same (as it is in Ada 2012). Declaration would be an instance, about the same length and wordiness as an array declaration. Yes, junk like slices, settable/retrievable bounds, and built-in operations that are rarely used would be gone, but so would the rather substantial overhead that those things entail. There'd be a lot more flexibility in implementation, which would allow better implementations. Virtually every array that I write has a fixed size (capacity really) and a usage high-water mark (a "length"). Having that generated automatically would be usually better than having to reinvent it literally every time I program something. (And as you've noticed repeatedly, Ada's type abstraction isn't good enough to make it practical to build anything reusable to do that.) >> One could do something similar for records, although I would probably >> leave >> them as in Ada and just allow user-definition of "." (via a getter/setter >> pair). > > Ditto. ??? The basic idea would be to eliminate the huge number of special cases that exist in Ada resolution and essentially make *everything* a subprogram call at it's heart. Ada did that for enumeration literals and that model makes sense for pretty much everything: object usage, indexing, selection, etc. It would be much easier to prove that resolution is doing the right thing (I don't think that would be practically possible for Ada). Randy.