From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	ip-172-31-65-14.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=3.0 tests=BAYES_00,NICE_REPLY_A,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.6
Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: "G.B." <bauhaus@notmyhomepage.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Aspect location in expression function.
Date: Wed, 25 May 2022 20:45:58 +0200
Organization: A noiseless patient Spider
Message-ID: <t6lth7$6qd$1@dont-email.me>
References: <t5o4sg$3oh$1@gioia.aioe.org> <t5oigj$pag$1@dont-email.me>
 <t6hlhq$vcu$1@dont-email.me> <t6j7se$8b1$1@dont-email.me>
 <t6kebj$npp$1@dont-email.me>
Reply-To: nonlegitur@notmyhomepage.de
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 25 May 2022 18:45:59 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="017c812674dc9e0868f526812d050bfb";
	logging-data="6989"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19u/LYlUr+TF0zQppZnIvvGAlZ0Bzxifzg="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.9.1
Cancel-Lock: sha1:7mwdUJhbw7ActNOdePyPd9/wuKI=
In-Reply-To: <t6kebj$npp$1@dont-email.me>
Content-Language: en-US
Xref: reader02.eternal-september.org comp.lang.ada:63880
List-Id: <comp.lang.ada>

On 25.05.22 07:20, Randy Brukardt wrote:
> "G.B." <bauhaus@notmyhomepage.invalid> wrote in message
> news:t6j7se$8b1$1@dont-email.me...
>> On 24.05.22 06:05, Randy Brukardt wrote:
> ...
>> Who cares to see "is abstract" if P is in a spec?
>> The implementer, I guess, but the client? Less so.
> 
> Any client that needs to declare an extension (pretty common in OOP),

Another, dare I say, more frequent way of being a client of a type
is being a caller of the type's subprograms, such as P, rather than
being an implementer of a type's concrete behavior. (The two can
overlap, but I'm thinking of the more frequent human clients here :) )

A case I'd single out is a type that comes with a factory F.
I'd expect the associated type T to be abstract. This goes
without saying! ;-) A client needs to know the "behavioral"
interface of T and also that of F.
   The "is abstract" then remains as helpful language technology,
but as seen inside the factory.

(So, I'd put "is abstract" last.)

> especially as "abstract" routines mostly are used with root types (and
> interfaces). I suppose you could "program by error" 

Not design errors, but mechanical errors duly output by the compiler.
The programmer will be programming by "following the language's rules".
IDEs and compilers will assist the programmer who is implementing
an abstract type. For example, the usual IDE has this suggestion
following its compiler's error message::

   Fix: "Add unimplemented methods"
(for)
   Error: "The type must implement[!] the inherited abstract method ..."

The IDE will do so if you answer "Yes" and programmers can provide their
own adjustments to template text that this mechanism will be using. Thus,
again, programmers can involve useful language technology in
a template's text. I remember some Ada tools offering similar features.