Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: Ichbiah 2022 compiler mode
Date: Sat, 14 Sep 2024 08:47:49 +0200
Organization: A noiseless patient Spider
Lines: 53
Message-ID: <vc3bil$1b33j$1@dont-email.me>
References: <vbc625$at65$1@dont-email.me> <vbdgs7$hedr$1@dont-email.me>
 <lybk10o4u7.fsf@pushface.org> <lk3fsvF7aaaU1@mid.individual.net>
 <vbtrmo$34n9$1@dont-email.me> <vbuarq$64hr$1@dont-email.me>
 <lkg1vvF1tp6U1@mid.individual.net> <vc39ib$1avpa$1@dont-email.me>
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: <vc39ib$1avpa$1@dont-email.me>
Bytes: 3487

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