Re: Why .ads as well as .adb?

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

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
       .      @       .