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!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: =?UTF-8?Q?Re:_How_to_get_Ada_to_=e2=80=9ccross_the_chasm=e2=80=9d?=
 =?UTF-8?Q?=3f?=
Date: Sat, 14 Jul 2018 18:48:57 +0300
Organization: Tidorum Ltd
Message-ID: <fqukb9F4sb5U1@mid.individual.net>
References: <1c73f159-eae4-4ae7-a348-03964b007197@googlegroups.com>
 <878t9nemrl.fsf@nightsong.com>
 <d64089d4-af9d-43d9-b72b-a73d3fff1f00@googlegroups.com>
 <bf8f8498-f017-47dd-bf1f-188c7ceb5b28@googlegroups.com>
 <62df3c25-057c-4cc5-a899-b91413613b83@googlegroups.com>
 <pici0g$svr$1@gioia.aioe.org>
 <7306c5a4-7810-4e5d-9896-124b9841832b@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net bsBlDWaG6pPJnkJdhWtKbgocbuDGcRqFndT1PBFAwqEdIMlNPz
Cancel-Lock: sha1:GOh9OWiu8zZfuNd0MCNH++4OgWk=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0)
 Gecko/20100101 Thunderbird/45.8.0
In-Reply-To: <7306c5a4-7810-4e5d-9896-124b9841832b@googlegroups.com>
Xref: reader02.eternal-september.org comp.lang.ada:53813
Date: 2018-07-14T18:48:57+03:00
List-Id: <comp.lang.ada>

On 18-07-14 17:28 , Shark8 wrote:
> On Saturday, July 14, 2018 at 4:07:16 AM UTC-6, Dmitry A. Kazakov wrote:
>>
>> I doubt there is any real problem in Ada that cannot be resolved keeping
>> *everything* backward compatible.
>
> There are some things that can't be fixed while keeping backwards
> compatibility and *NOT* adding yet-another-way-to-do-this; which
> is what C++ did with it's myriad of pointers and references.
>
> A couple of good examples:
     [snip]
> * Protected objects (What's in the private section ought to be the body, IMO.)
>        protected type Signal_Object is
>           entry Wait;
>           procedure Signal;
>           function Is_Open return Boolean;
>        private
>           Open : Boolean := False; -- WHY ARE WE EXPOSING THIS?
>        end Signal_Object;

The answer to your shouted question is (as I suspect you know): because 
a protected type declaration defines a type that will be used to declare 
objects, and the compiler must know the size, structure and alignment of 
the data contained in the object before it can make code to create such 
an object.

If the private component declarations were moved to the body, clients 
of the package that defines the protected type would come to depend on 
the body of that package.

Nevertheless, as such a dependency is usually not fatal (resulting also 
from generics) I don't see why Ada could not be extended to allow the 
private component declarations to be optionally postponed to the body, 
for example with this declaration syntax (just a what-came-first-to-mind 
sketch):

    protected type Signal_Object is
       entry Wait;
       procedure Signal;
       function Is_Open return Boolean;
    private in body; -- NOT current Ada!
    end Signal_Object;

and this body syntax (the declarations of the object components come 
first, because the operations must see them):

    protected body Signal_Object is
       Open : Boolean := False;  -- NOT current Ada!
       entry Wait
          ...  -- Body of Wait.
       ... -- Bodies of Signal and Is_Open.
    end Signal_Object;

I don't see any backward compatibility problem with this.

Of course it is "yet another way" to declare the components of a 
protected type. So what? If you convince enough people that this kind of 
protected declaration is desirable, you might be able to convince the 
ARG to add it to Ada. I think it can be done without breaking backward 
compatibility with current Ada.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .