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!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: Proposal: Auto-allocation of Indefinite Objects Date: Thu, 20 Aug 2020 18:30:07 -0500 Organization: JSA Research & Innovation Message-ID: References: <94a54092-a56f-4a99-aaec-08dd611c8fd8@googlegroups.com> <8a502b6c-4609-4cd8-b292-5797fe6421e1n@googlegroups.com> Injection-Date: Thu, 20 Aug 2020 23:30:08 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="29142"; 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:59771 List-Id: "Dmitry A. Kazakov" wrote in message news:rhmd3m$1eql$2@gioia.aioe.org... > On 20/08/2020 02:10, Randy Brukardt wrote: >> "Dmitry A. Kazakov" wrote in message >> news:rgr267$1o1n$1@gioia.aioe.org... >>> No, from the abstraction point of view they do not. They indeed abstract >>> the memory allocation aspect, but they do that at the cost of >>> *everything* >>> else. Unbounded_String is no string anymore. Container is neither array >>> nor record type. Unbounded_String must be converted forth and back. For >>> containers I must use ugly hacks like iterators to make them resemble >>> arrays and records introducing whole levels of complexity to fight >>> through >>> every time the compiler or I miss something. >>> >>> In most cases I prefer to keep a clear array or record interface at the >>> expense of manual memory management. >>> >>>> There's no free lunch. >>> >>> I think with a better type system there could be a whole banquet. (:-)) >> >> Maybe. but IMHO a better type system would get rid of arrays and strings >> altogether and only have containers/records of various sorts. The >> complexity >> of having both solving the same problems (not very well in the case of >> arrays/strings) doesn't buy much. I suspect that a user-defined "." as >> you've proposed elsewhere would eliminate most of the rest of the >> problems >> (and unify everything even further). > > But records and arrays are needed as building blocks of containers. How > would you get rid of them? There's no reason that a compiler couldn't "build-in" a simple bounded vector container as the basic building block. We already do that for things like Ada.Exceptions, Unchecked_Conversion, and Unchecked_Deallocation, so it's no harder to do that for a vector. (Probably would need some sort of fixed vector for interfacing purposes as well, to deal with other language's and/or system's memory layout.) 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). Randy.