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: Mon, 3 Jun 2019 17:50:00 +0300 Organization: Tidorum Ltd Message-ID: References: <28facad3-c55f-4ef2-8ef8-004925b7d1f1@googlegroups.com> <12ffe476-35a7-4442-994e-9a03972619bc@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net l7cgQK6t5cAhHq8mQctYdQhjSmfJa+lB+rR/yoDy8eVoKclnHe Cancel-Lock: sha1:Y4e24ypfp0msLrHN86odVTBNtzY= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <12ffe476-35a7-4442-994e-9a03972619bc@googlegroups.com> Xref: reader01.eternal-september.org comp.lang.ada:56441 Date: 2019-06-03T17:50:00+03:00 List-Id: On 19-06-03 16:37 , John Perry wrote: > Thanks to everyone for the replies. Personally, I find three of them > especially compelling: > > "As a teacher, I keep fighting with students who jump to writing > bodies too early." > > [I know exactly what this is like.] The separation (and early creation) of .ads files from .adb files was the main reason cited for the success of the first Ada project at my alma mater (a Prolog system -- this was during the "5th generation" fad). That project had markedly fewer integration and interfacing problems than earlier projects implemented in (an extended) Pascal. > "teams can work separated from each other as needed, without the > project having to distribute all of the implementation to everyone" > > [Having separate specification files against which one can *compile* > would be useful, not just convenient, though I think it's arguable > that one can do this in Oberon, too, via .smb files and > documentation.] If an Ada project needs to use an Ada library that is not open-source and was developed by someone else, the library provider can deliver the .ads source files to define the library API, but deliver only the object code for the .adb files, thus keeping the library implementation secret. Can Oberon .smb files do that? In Ada this can be done even if the library is actually implemented in some other language such as C. > "convenience" > > [not a direct quote, but several people point to this, and until I > read their explanations I thought the convenience ran in the other > direction] When I write client code for a package, I find it much more convenient to study the package's interface from its .ads file, because the .ads file is usually shorter than the .adb file and contains only information useful to the client (up to the "private" part). However, I admit that a smart IDE could display a filtered view of a "combined .ads/.adb" file, showing me only the interface and not the implementation. > So I was surprised that some people made absolute negations of the > possibility along these lines: > > "You can't generate specification from implementation." That is true, IMO, for current Ada, but I'm sure that Ada could be extended with pragmas or keywords to allow a combined .ads/.adb file from which a "pure .ads" could be extracted. But I don't see any advantage in that, given the other advantages of separate .ads and .adb. > I especially wonder this since one of them had just referred to > gnatchop, whose online documentation provides an example that does > precisely that [1]. No, gnatchop reads a source file that is a simple concatenation of any number of .ads and .adb files, and just finds the boundaries of the concatenated files and spits out the separated (de-concatenated) files. It is a bit like "unzip" but uses Ada syntax to separate out the individual files from the "archive" (the concatenated file). Ada compilers other than GNAT accepted such concatenated input source files as "compilations". Gnatchop was implemented to help apply GNAT to such source files. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .