Why *.adb and *.ads?

Why *.adb and *.ads?

[Andrew Shvets]

I'm curious, why do the source files in Ada have the file endings of *.ads and *.adb? Is there a reason for this? Or any background story?

Re: Why *.adb and *.ads?

[Jeffrey R. Carter]

On 01/01/2018 09:15 PM, Andrew Shvets wrote:
> I'm curious, why do the source files in Ada have the file endings of *.ads and *.adb? Is there a reason for this? Or any background story?

They don't. There are no source files in Ada. The ARM talks about the text of a 
compilation, which is divided into lines by line terminators, since comments are 
terminated by line terminators. But it says nothing about source files or file 
names.

It is normal on most computer systems for the text of a compilation to be in a 
file, but this is not required by the standard.

Ada-83 compilers reequired, and many compilers for later versions of the 
language used, the concept of a compilation library. One of the purposes of this 
was to associate Ada unit names with file names. On such systems, a source file 
could have any name at all. One instructed the compilation library to associate 
one or more Ada units with a file name, and then the compilation system knew 
where to find those units.

Some of those systems had recommended file-naming techniques. Rational liked 
name.1.ada for specs and name.2.ada for bodies. Janus/Ada recommends .pkg for 
packages. Others liked things like name.ada for specs and name_b.ada for bodies.

Beginning with Ada 95, the standard no longer required the use of a compilation 
library. GNAT decided not to use one, and instead to associate units with files 
through default file-naming rules. They chose name.ads for specs and name.adb 
for everything else. There are ways to use other file names, but in general it's 
usually easiest to go along with the default names.

-- 
Jeff Carter
"If you think you got a nasty taunting this time,
you ain't heard nothing yet!"
Monty Python and the Holy Grail
23

Re: Why *.adb and *.ads?

[Mace Ayres]

Andrew, you may think of the *.abs and *.abb as source code in the tradition way. The *.ads is the speficition (the ‘s’ of ads) file, which specifies the sub programs (functions, procedures) types, and other components of the (package). 
The corresponding *.adb is the full body, elaborated, details of the specifications (promise of functions, procedures, types, etc.) specified in the *abs specification. 

This provides rigorous delivery of the abstraction aspect of Ada. Think of hiring a very reliable consultant to build x, which will do various things in a safe and reliable way. The contract you sign promises the WHAT of what will be delivered, the specifications in the *abs file. The contractor plans, schedules, gather resources and supervises the delivery of the specification. He is the *adb, the actual work that is done.

You don’t need to see all the details of how the work is done. In fact you, or other components of the overall program, don’t want to know. If the contractor uses Bob instead of Alice to do part of x, you don’t care as long the the specification of delivery remains consistent. 


—— Psuedo code,, not clean Ada syntax
test.abs .. 
procedure say_hello (message :string in);
procedure dubs. ...;
function example ....  ;
end test;  — speficiation 

test,adb ———————- 
Procedure say_hello is 
Begin 
put_line(message); 
end; — say_hello

function example (,,,, return string) 
begin
 return (“I am not ready yet.”)
end example;

end test.  — dbody 

to use procedue say_hello somewhere, I have” 
If happy then 
  say_hello (“i am happy”); 

else 
  say_hello(“Not so happy”); 
end if; 

If I code:
bucket := example;
put (bucket);
 I see there is a contract for a function called exaple that returns a string. It’s nothing yet, but I can later elaborate functionality of example without changing the ingterface. If I change the interface *.ads specification I have to change the body’s ingterface to match in the adb file too.
The details of the implementation of say_hello may change in the body *.adb, as long as the procedure definition in the *.abs and *adb domain the same. 

t

Why *.adb and *.ads?

[Mace Ayres]

Andrew, you may think of the *.abs and *.abs as source code in the tradition way. The *.ads is the speficition (the ‘s’ of ads) file, which specifies the sub programs (functions, procedures) types, and other components of the (package).
The corresponding *.adb in the full body, elaborated, details of the specifications (promise of functions, procedures, types, etc.) specified in the *abs specification.

This provides rigorous delivery of the abstraction aspect of Ada. Think of hiring a very reliable consultant to build x, which will various things in a safe and reliable way. The contract you sign promises the WHAT will be delivered, the specifications in the *abs file. The contractor plans, schedules, gather resources and supervises the delivery of the specification. 

You don’t need to see all the details of how the work is done. In fact you, or other components of the overall program, don’t want to know. If the contractor uses Bob instead of Alice to do part of x, you don’t care as long the the specification of delivery remains consistent.

test.abs ..
procedure say_hello (message :string in out);
end test;  — speficiation

test,adb ———————-
Procedure say_hello is
Begin
put_line(message);
end test.  — body

to use procedue say_hello somewhere, I have”
If happy then 
  say_hello (“i am happy”);
else
  say_hello(“Not so happy”);
end if;
The details of the implementation of say_hello may change in the body *.adb, as long as the procedure definition in the *.abs and *adb domain the same.

t

Re: Why *.adb and *.ads?

[Norman Worth]

Andrew Shvets wrote:
> I'm curious, why do the source files in Ada have the file endings of *.ads and *.adb? Is there a reason for this? Or any background story?
> 
This has nothing to do with the Ada language.  It is a characteristic of 
the GNAT Ada compiler, which is probably the most common Ada compiler. 
Other compilers may use other tags to identifier their source files. 
I've seen .ada commonly.

Re: Why *.adb and *.ads?

[Dennis Lee Bieber]

On Sat, 27 Jan 2018 08:45:09 -0700, Norman Worth <nworth@comcastNOSPAM.net>
declaimed the following:

>Andrew Shvets wrote:
>> I'm curious, why do the source files in Ada have the file endings of *.ads and *.adb? Is there a reason for this? Or any background story?
>> 
>This has nothing to do with the Ada language.  It is a characteristic of 
>the GNAT Ada compiler, which is probably the most common Ada compiler. 
>Other compilers may use other tags to identifier their source files. 
>I've seen .ada commonly.

	.1.ada and .2.ada is the variant I've seen most often outside of
.ads/.adb. It's even a built-in alternative for GPS.

	Even the Ada83 cross-compiler I'd had to use on my last employment
seemed to be configured to the GNAT .ads/.adb convention (along with a few
other extensions for processor specific code -- apparently how they handled
the equivalent of dual code trees; one for target, one for simulation
system). Granted, this may have been a result of some historical
refactoring so they could use GNAT on Windows for test compilation/editing,
as telnet into a VMS box (virtual for the last half decade or so) is not
comfortable -- VMS editors don't translate well to non-VT keyboards.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[OT] VMS editors and PC keyboards, was: Re: Why *.adb and *.ads?

[Simon Clubley]

On 2018-01-27, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> Granted, this may have been a result of some historical
> refactoring so they could use GNAT on Windows for test compilation/editing,
> as telnet into a VMS box (virtual for the last half decade or so) is not
> comfortable -- VMS editors don't translate well to non-VT keyboards.

Assuming you are using PC keyboards with all the normal keys on
them, you could try using PuTTY as it has a couple of keyboard
layout options when working with either VMS systems or editors
with a EDT keypad option.

The only keypad key I don't have available when using an editor
in EDT keyboard mode is "delete word" which I never used anyway.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Why *.adb and *.ads?

[Mace Ayres]

Ada, like Pascal,  on which Ada is substantially based, requires declaration of functions, procedures, and other elements (types I think)  before they are used, a pre-declaration. This is unlike other languages that allows you declare and use and variable like Basic, or Python or the like where you can invent things about anywhere on the fly. The Pascal/Ada “definition” or pre declaration defines the type name, parameters in and return types, and supports the Strong Typing and safety characteristics of Ada.  The compiler can then enforce proper use of the functions, procedures, an types later in the program, because it has a reference standard, the predeclaration/definition to validate proper use and compilation.  In Pascal, the declarations simply had to be put before the full body of the procedure/function, all in one file.

With GNAT you can put the specification/predeclaration and body (full source code not just the high level definition) in a single file.

But, by using the *.ads to contain the specification and the *.adb to contain the full elaboration, the pre-declaration/specification and subsequent body distinction are enforced, both logically for the developer, and compiler.

Also, if you have a large body file *.adb, you can look at the *.ads and quickly see all the functions and procedures that are in the body, though Ada best practices says not to put loo many procedures and functions in a *.adb file (package). In the past, I have seen, and have myself, put a large comment section at the start of a body of code that listed all the following procedures/functions, with parameters, and their intended use, in languages that did not specifically require prior declarations.This useful in large long lived programs where many developers may work on the code over time. It provides a quick way to see at a high level, what’s in a large body of code.

Also, pre declaration/specification is a solid step forward in CS languages when it emerged some decades past.