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!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Why .ads as well as .adb? Date: Wed, 5 Jun 2019 17:28:09 +0300 Organization: Tidorum Ltd Message-ID: References: <28facad3-c55f-4ef2-8ef8-004925b7d1f1@googlegroups.com> <87woi0xtwm.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net uhifV2Eps6zMhvx+7Y0WuQnll4luEqVIXso5USSixD8reAiL30 Cancel-Lock: sha1:Fa2BkprpYtlIjPg5DESg0EKQoUg= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: Xref: reader01.eternal-september.org comp.lang.ada:56488 Date: 2019-06-05T17:28:09+03:00 List-Id: On 19-06-05 15:58 , Maciej Sobczak wrote: >> On the other hand, I like it that I can get a first impression of >> an Ada program by reading just the .ads files. > > This. This is important. I have seen the suggestion to treat spec > files as a low-level requirements document, to be completed by the > body. I imagine that is how most Ada programmers design programs -- divide the thing into packages, write the specs for each package to document the division of responsibilities and functions, and then implement the bodies according to the specs. (Of course this means that the .ads files should contain lots of requirements written as comments or contracts.) In the SW processes used in ESA projects, these steps are often separated into successive phases: architectural design first, detailed design+coding second, with the two phases separated by a formal review meeting. > In particular, it is very difficult to explain this concept to > beginners, because in simple examples the redundancy of syntax is > just shocking - the package spec looks like copy-paste of signatures; The "redundancy" applies only to subprograms, and is in fact not redundant once overloading is used. Most of my specs contain mostly type declarations, with a smattering of subprogram declarations -- no, in fact most of my specs contain mostly comments to explain the types and to specify and explain what the subprograms (should) do. Most subprograms in the bodies are private and are not declared in the spec. > and arguably this is how some of the specs are born in practice. Usually the body is initialized as a copy of the relevant parts of the spec. GPS even has a menu command for this, which generates an .adb file, with null subprogram bodies, from an .ads file. I copy declarations from body to spec only if I find, while implementing the program, that I must publish something that I originally did not intend to make visible to clients. > The language that forces me to copy-paste stuff between files is not > inviting me to study it more deeply. Hmm. The same copy-paste applies to C (header files vs .c files). >> Apart from all the other reasons already given, keeping spec and >> body in the same file can cause compilation-order problems. > > Only if you assume that the compiler reads the file only once and > therefore must validate everything in a single pass. No, the compiler does not *have* to validate everything at once, but mixing .ads and .adb in the same file means (as I said) that the compiler must have the ability to avoid validating the .adb part if it is only "withing" the file. This makes the compiler more complex, although the fact that Ada (unlike some other languages) does not allow application-defined syntax extensions (such as macros) would keep it tractable. > Which is not the case anyway, not even in Ada Explain why an Ada compiler should have to read a source file multiple times, please. GNAT does it (for .ads files and in some other cases) but some compilers do not, AFAIK. If your point is only that most present-day compilers are (internally) multi-pass, that is true, but I don't see the relevance. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .