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!.POSTED!not-for-mail
From: "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org>
Newsgroups: comp.lang.ada
Subject: Re: Why .ads as well as .adb?
Date: Mon, 3 Jun 2019 19:00:20 +0200
Organization: Also freenews.netfront.net; news.tornevall.net;
 news.eternal-september.org
Message-ID: <qd3jn6$kn8$1@dont-email.me>
References: <28facad3-c55f-4ef2-8ef8-004925b7d1f1@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 3 Jun 2019 17:00:22 -0000 (UTC)
Injection-Info: reader02.eternal-september.org;
 posting-host="b7b4e139e89781ada0915edd44c6fd08";
	logging-data="21224"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX18qiSaeyTNtBNclLKlBUqz+EmI1Qll3vlA="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.0
Cancel-Lock: sha1:IAVZfSnmLsndFjuJ2td0fk5JPUY=
In-Reply-To: <28facad3-c55f-4ef2-8ef8-004925b7d1f1@googlegroups.com>
Content-Language: en-US
Xref: reader01.eternal-september.org comp.lang.ada:56443
Date: 2019-06-03T19:00:20+02:00
List-Id: <comp.lang.ada>

On 6/2/19 2:48 AM, John Perry wrote:
> 
> As far as I can tell, though, Ada has stuck with the two separate files, rather than, say, generating an .ads from an .adb with export markup.
> 
> Is there a reason Ada hasn't moved to this simpler structure?

First, let me point out that your specification is GNAT-specific, but your body 
is compiler-independent. I'm going to presume that the generation of the spec 
from the body was faulty.

Others have given you the good reasons related to S/W engineering in the large 
(more than 1 person). They provide a formal and compiler-checked way to state 
what each person is working on, and allow the development of parts of the S/W 
that depend on other parts that have not been implemented yet.

I have not seen any responses that address the use of specs to represent and 
check high-level design decisions. This can be very helpful.

Nor have I seen any responses that deal with specs as a way to deal with the 
limitations of the human brain. When a system reaches a certain size, whether 
developed by a single person or a team, it becomes impossible to keep the entire 
system in one's head. Specs reduce the amount of information that must be retained.

I recall reading a quote by a famous S/W engineer: "I have only a small brain 
and must learn to live with it." I don't recall who, and I can't find it on 
line. Reducing the amount of information kept in the brain is what he meant by 
learning to live with it. Separate specs are a mechanism for that.

In another post, you wrote

> So I was surprised that some people made absolute negations of the possibility along these lines:
> 
>     "You can't generate specification from implementation."
> 
> I especially wonder this since one of them had just referred to gnatchop, whose online documentation provides an example that does precisely that [1].

Note that gnatchop does not generate specifications from bodies, and the example 
does not show that. It shows an input file containing 2 compilation units, a 
spec and a body. gnatchop produces a single file for each compilation unit in 
its input.

-- 
Jeff Carter
"I fart in your general direction."
Monty Python & the Holy Grail
05