From mboxrd@z Thu Jan 1 00:00:00 1970 Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ichbiah 2022 compiler mode Date: Sat, 14 Sep 2024 08:47:49 +0200 Organization: A noiseless patient Spider Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 14 Sep 2024 08:47:49 +0200 (CEST) Injection-Info: dont-email.me; posting-host="5acee75998ca5545fb94acf55ed3ca51"; logging-data="1412211"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/P4q+yAs1DdHMgipNpn5kRGTjeb6lmmHM=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:oArndBhOdiVmDl0XJgC/ijMOg0c= Content-Language: en-US In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:66372 List-Id: On 2024-09-14 08:13, Randy Brukardt wrote: > I think the parallel block is more useful for general tasking. The advantage > of using parallel structures is that they look very similar to sequential > structures, and one lets the system do the scheduling (rather than trying to > figure out an organization manually). Tasking is not about scheduling. It is about program logic expressed in a sequential form. It is about software decomposition. Parallel constructs simply do not do that. > One of the advantages of the model I'm thinking about is that it separates > concerns such as parallel execution, mutual exclusion, inheritance, > organization (privacy, type grouping), and so on into separate (mostly) > non-overlapping constructs. To me it is exactly *one* construct: inheritance. You should be able to inherit from an abstract protected interface at any point of type hierarchy in order to add mutual exclusion: type Protected_Integer is new Integer and Protected; > Ada started this process by having tagged types > a separate construct from packages; I see modules and types as unrelated things. you need both to get traditional OOP, > but you can also construct many structures that are quite hard in > traditional "one construct" OOP. I think that ought to be done for all > constructs, and thus the special task and protected constructs ought to go. Constructs yes, they must go. It must be all inheritance. The concepts must stay. > We already know that protected types cause problems with privacy of > implementation and with inheritance. Tasks have similar issues (admittedly > less encountered), so splitting them into a set of constructs would fit the > model. The problems are of syntactic nature, IMO. There is an issue with an incomplete inheritance model. You need not just complete overriding but also more fine mechanisms like extension in order to deal with entry point implementations. The same problem is with constructors and destructors, BTW. What should really go is Ada.Finalization mess replaced by a sane user construction hooks model for all types, class-wide ones included. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de