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!aioe.org!.POSTED.2uCIJahv+a4XEBqttj5Vkw.user.gioia.aioe.org!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Proposal: Auto-allocation of Indefinite Objects Date: Sun, 23 Aug 2020 14:29:14 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <94a54092-a56f-4a99-aaec-08dd611c8fd8@googlegroups.com> <8a502b6c-4609-4cd8-b292-5797fe6421e1n@googlegroups.com> NNTP-Posting-Host: 2uCIJahv+a4XEBqttj5Vkw.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.9.2 Xref: reader01.eternal-september.org comp.lang.ada:59789 List-Id: On 23/08/2020 06:48, Randy Brukardt wrote: > "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, That alone disqualifies it in my eyes. > about the same length and wordiness as an array declaration. Plus a dozen of tagged helper types... > 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. These is a vital part of array interface to me. Moreover I want lost of other junk there, like ranges being proper types, like multidimensional slices/subarrays, indicator sets (to specify array's diagonal) etc. > 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.) I agree with that, but disagree with the solution. In my view arrays must be 1) generalized, 2) abstracted to support user-defined implementations. The challenge is to have a type system where one could design a 3-band matrix type usable where a dense matrix type is expected. >>> 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. Yes, I agree everything must have a corresponding primitive operation. But there are cases when such operations must be static like "." of a record types or implemented per delegation to a generalized implementation like integer or string literals. > 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). I think that not only Ada's, but even C++'s type system, could be expressed by means of a more powerful one. After all it is possible to write a compiler for both... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de