From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.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" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Musing on defining attributes and the ability to define an
 "abstract type X"-interface.
Date: Tue, 8 Aug 2017 19:44:46 -0500
Organization: JSA Research & Innovation
Message-ID: <omdltu$m87$1@franka.jacob-sparre.dk>
References: <9617c73b-e23e-405b-8544-4d17e7e3ad61@googlegroups.com>
 <okpnfb$9du$1@gioia.aioe.org>
 <28512bf1-0c2c-400f-a24f-cc7e0eb8a02d@googlegroups.com>
 <87h8y67trd.fsf@jacob-sparre.dk>
 <ae46a44e-ee1e-42f6-ae8d-a02ae012e31d@googlegroups.com>
 <om32rl$ess$1@franka.jacob-sparre.dk>
 <36a1a83d-f3d7-4e3c-827d-addeadc28ccc@googlegroups.com>
 <omas4f$s1n$1@franka.jacob-sparre.dk> <ombrm4$18q4$1@gioia.aioe.org>
Injection-Date: Wed, 9 Aug 2017 00:44:47 -0000 (UTC)
Injection-Info: franka.jacob-sparre.dk;
 posting-host="rrsoftware.com:24.196.82.226";
	logging-data="22791"; 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: news.eternal-september.org comp.lang.ada:47653
Date: 2017-08-08T19:44:46-05:00
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ombrm4$18q4$1@gioia.aioe.org...
...
>> Remember that the language is maintained almost exclusively by 
>> volunteers -
>> people are not signing up to make changes for the sake of changes.
>
> Even more important to concentrate resources on real problems rather than 
> piling up kludges upon kludges. It was possible for Ada 95, it should be 
> possible now.

Experience is that the volunteers start to disappear if one is not working 
on new, important features for the language. Changing the underpinnings --  
with its high risk of making incompatible changes -- is not likely to get 
much traction. UNLESS it is tied directly to the solution of some high 
priority problem.

My main point to the OP is to find that high priority problem, *then* 
explain how a language design change would help to fix it. In the original 
post, there was nothing about problems, and next to nothing about what sort 
of language design change was contemplated, just a bunch of fluff about 
making the language more consistent. News flash: no real language is very 
consistent. It can't be and stilll be efficiently implementable. Ada has the 
additional constraint of remaining compatible in the vast majority of cases. 
That makes it hard to make any wholesale changes.

                                               Randy.