Re: Why .ads as well as .adb?

[John Perry <john.perry@usm.edu>]

On Monday, June 3, 2019 at 9:50:03 AM UTC-5, Niklas Holsti wrote:
> > "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?

Yes; that's the entire point of an .smb file. The Oberon compilers I'm familiar with generate both symbol (.smb) and object files (.o or .class, depending on the target). I've tested that they will check a module against .smb, without having an object file.

In Native Oberon, unexpected record fields are kept secret [1]. Wirth states in "Modula-2 and Oberon" [2] that symbol files have an advantage over source files, in that the compiler can record a version number with the file, and automatically update it.

> In Ada this can be done even if the library is actually implemented in 
> some other language such as C.

An Oberon compiler that targets native code allows one to create modules that define interfaces to C files [3]. Another, which targets the JVM, allows one to create modules that define interfaces to Java class files. [4]

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

Right, this latter is what I'm referring to in general.

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

That's fine; as I said, I'm curious. I've noticed that Ada's designers aren't reticent to adopt what they think are good ideas from other languages (e.g., Eiffel's contracts) so that made me wonder why the .ads/.adb distinction was retained, at least in gnat. (I'm not actually aware if that's required by the language itself.)

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

I completely misunderstood that. Thank you.

BTW, in case it hasn't been clear: there are plenty of ways I think Ada is far superior to Oberon. This is just one aspect of Oberon that originally I didn't like (when I was a Modula-2 programmer), and came to appreciate greatly only later.

john perry

[1] inf.ethz.ch/personal/wirth/Articles/Modula-Oberon-June.doc

[2] www.ethoberon.ethz.ch/native/compiler/obj081200/ObjectFile.html

[3] miasap.se/obnc/man/obnc.txt; see "Interfacing to C".

[4] github.com/lboasso/oberonc