Multiple procedures in the same adb file?

[John Smith]

Hello,

I have a question, what if I want multiple procedures in the same adb file, can that be done? This is my code right now:

===============================================================================
procedure a_test(A, B : Integer; C : out Integer) is
begin
C := A + B;
end a_test;

procedure test_procedure is
output : Integer;
begin
a_test(23, 34, output);
end test_procedure;
===============================================================================

And this is the compilation error that I got:
===============================================================================
% gnatmake -g test_procedure.adb
gcc -c -g test_procedure.adb
test_procedure.adb:16:01: end of file expected, file can have only one compilation unit
gnatmake: "test_procedure.adb" compilation error
===============================================================================

Basically, if I have the program entrance function, how do I add others so as to break up the logic of the program?

[John Smith]

One more question. Can a file have multiple procedures (as well as a mix of procedures and functions) as well as functions in them as well? Or would I need to put them into a package?

What does the error "end of file expected, file can have only one compilation unit" mean exactly?

[Robert A Duff]

John Smith <yoursurr...@gmail.com> writes:

> I have a question, what if I want multiple procedures in the same adb

> file, can that be done? ...

The simplest thing is to have a single procedure that is your main
procedure, and everything else in packages or generic packages.
The main procedure goes in one file, and each package spec and each
package body in a separate file. The naming convention is x.ads for
specs and x.adb for bodies, where x is the name of the compilation_unit
(i.e. the package spec or body or procedure body).

You don't have to do that. There are ways to use different naming
conventions, put multiple compilation units in one files, etc,
but they are a nuisance. Look up gnatchop, pragma Source_File_Name,
and project files if you really want to do it differently than
the standard GNAT way.

The main procedure doesn't need a spec, but it can have one.
It is unwise to have procedures outside of packages (other than the
main procedure, which Ada annoyingly doesn't allow to be in a package).

For medium-to-large programs, use child packages. A single root package
(or small number of them), with everything else being child, grandchild,
and so on of the root(s). The main procedure can be a root, or can be a
child of your single root package.

> ===============================================================================
> procedure a_test(A, B : Integer; C : out Integer) is
> begin
> C := A + B;
> end a_test;
>
> procedure test_procedure is
> output : Integer;
> begin
> a_test(23, 34, output);
> end test_procedure;
> ===============================================================================

Note that you could nest a_test inside test_procedure.

It's a good idea to follow common style rules, such as calling those
A_Test and Test_Procedure. (But the file names should be in lower
case.)

- Bob

[Jeffrey Carter]

On 01/11/2015 11:37 AM, John Smith wrote:
>
> ===============================================================================
> procedure a_test(A, B : Integer; C : out Integer) is
> begin
> C := A + B;
> end a_test;
>
> procedure test_procedure is
> output : Integer;
> begin
> a_test(23, 34, output);
> end test_procedure;
> ===============================================================================
>
> And this is the compilation error that I got:
> ===============================================================================
> % gnatmake -g test_procedure.adb
> gcc -c -g test_procedure.adb
> test_procedure.adb:16:01: end of file expected, file can have only one compilation unit
> gnatmake: "test_procedure.adb" compilation error
> ===============================================================================

GNAT only allows a single compilation unit per file. A compilation unit is a
subprogram declaration, subprogram body, package specification, or pkg body. You
have 2 subprogram bodies in a single file, so GNAT rejects it. Some other
compilers have no problem with multiple compilation units in a single file.

for a simple program like this you probably want to nest A_Test in Test_Procedure:

procedure Test_Procedure is
procedure A_Test (A : in Integer; B : in Integer; C : out Integer) is
begin -- A_Test

C := A + B;

end A_Test;

Output : Integer;
begin -- Test_Procedure
A_Test (A => 23, B => 34, C => Output);
end Test_Procedure;

--
Jeff Carter
"It's all right, Taggart. Just a man and a horse being hung out there."
Blazing Saddles
34

[John Smith]

Hello Bob,

Thanks, that was really helpful. I got it to work by making the appropriate *.ads and *.adb files. I also had it working as a nested function.

It seems a tad tedious at first, but it does make sense. Heck, even C/C++ recommends a similar approach. You want to separate the declaration from the implementation.

On Sunday, January 11, 2015 at 2:51:32 PM UTC-5, Robert A Duff wrote:

[Robert A Duff]

John Smith <yoursurr...@gmail.com> writes:

> Thanks, that was really helpful.

You're welcome.

>... I got it to work by making the appropriate *.ads and *.adb files.

>I also had it working as a nested function.
>

> It seems a tad tedious at first, ...

Yes, it's a nuisance for small programs. But for large programs,
one compilation_unit per file with a file-naming convention is
really the only sensible way. But I must admit, I'd prefer GNAT
to be able to handle multiple compilation_units per file without
so much horsing around.

That's partly because when I'm debugging GNAT, I'm often working
with very small test programs. If a customer hands me a huge
program that causes GNAT to crash, I'll usually try debugging
it directly first, but if I can't figure it out quickly that way,
I'll try making a small cut-down test that crashes in the same way.
If the small test case contains 30 lines of code in 5 files,
that's just a nuisance. So I use gnatchop.

Most bug reports are already small. The biggest one I had to
deal with at AdaCore was about 37,000,000 lines of code.

> ...but it does make sense. Heck, even C/C++ recommends a similar

> approach. You want to separate the declaration from the
> implementation.

Right, same idea.

- Bob

[Niklas Holsti]

On 15-01-11 21:51 , Robert A Duff wrote:
> It is unwise to have procedures outside of packages

Why "unwise"? I agree it is unusual, but I find it is sometimes useful,
in particular to have subprograms which are children of packages but are
their own compilation units. In a layered architecture, such subprograms
are sort of in a layer between the higher layer that contains the
declaration of the parent package, and the lower layer that contains the
body of that package.

In language-lawyer terms, perhaps such subprograms are not really
"outside of packages", because child units are in some sense "inside"
their parents, but the child subprograms are not "inside" any package in
terms of source-code files.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .

[John Smith]

37,000,000 lines of code? What was the application supposed to do? Simulate planet earth?

On Sunday, January 11, 2015 at 4:02:21 PM UTC-5, Robert A Duff wrote:

[Robert A Duff]

Niklas Holsti <niklas...@tidorum.invalid> writes:

> On 15-01-11 21:51 , Robert A Duff wrote:
>> It is unwise to have procedures outside of packages
>
> Why "unwise"?

Because sometimes you need to add new stuff (another related procedure,
for example), and then there's no good place to put it. If the existing
procedure is in a package, then that's where you put it.

This happened to me: Existing code:

function Some_Root_Package.Some_Function(...) return String;

Now I happen to know that it always returns String(1..20).
And returning known-length strings is more efficient,
and this one is a bottleneck, so it's worth changing to
something like:

subtype String_20 is String(1..20);
function Some_Function(...) return String_20;

But that doesn't work without adding a new package, which breaks
compatibility. And this was a widely-used library, so I couldn't do
that. And String_20 really doesn't belong in Some_Root_Package,
nor anywhere else than the package that Some_Function is (directly) in
(which didn't exist!).

If the original programmer had put Some_Function in a child package
Some_Root_Package.Some_Package in the first place, then I wouldn't have
had these problems.

I admit: these concerns are only significant for widely-used libraries.
If I had been working on a program instead of a library, I would have
just moved Some_Function into a package, and modified all the call
sites. But it's probably a good idea to get in the habit of using
"library-programming" style even when doing "program-programming",
if it's not too much trouble.

Besides, it complicates the language quite a bit to have misc stuff
allowed as compilation units (e.g. task body subunits). I would prefer
that the only unit of separate compilation be the package (and maybe
generic package).

>... I agree it is unusual, but I find it is sometimes useful,

> in particular to have subprograms which are children of packages but are
> their own compilation units. In a layered architecture, such subprograms
> are sort of in a layer between the higher layer that contains the
> declaration of the parent package, and the lower layer that contains the
> body of that package.

Sure, but you can do that with another package just as well as
with a procedure.

> In language-lawyer terms, perhaps such subprograms are not really
> "outside of packages", because child units are in some sense "inside"
> their parents, but the child subprograms are not "inside" any package in
> terms of source-code files.

Yes, you're right. In fact, everything is logically nested within
package Standard, so everything is in a package. But I meant that
everything should be physically/textually nested within a package,
and packages (and generic packages) should be the only
separately-compiled things. And main procedures should be
(textually) in packages, instead of as standalone procedures
(and that part is not Ada -- just my preference for how it ought
to be!).

- Bob

[Robert A Duff]

John Smith <yoursurr...@gmail.com> writes:

> 37,000,000 lines of code? What was the application supposed to do?
> Simulate planet earth?

;-)

I think it was air traffic control or railroad switching control,
or something like that.

- Bob

[Robert A Duff]

Oops, sorry for the email. I meant to post to the newsgroup -- hit the
wrong button.

- Bob

[Robert A Duff]

[J-P. Rosen]

Le 12/01/2015 01:53, Robert A Duff a écrit :
> This happened to me: Existing code:
>
> function Some_Root_Package.Some_Function(...) return String;
>
> Now I happen to know that it always returns String(1..20).
> And returning known-length strings is more efficient,
> and this one is a bottleneck, so it's worth changing to
> something like:
>
> subtype String_20 is String(1..20);
> function Some_Function(...) return String_20;
>
> But that doesn't work without adding a new package, which breaks
> compatibility. And this was a widely-used library, so I couldn't do
> that. And String_20 really doesn't belong in Some_Root_Package,
> nor anywhere else than the package that Some_Function is (directly) in
> (which didn't exist!).

Put the function in a package, and declare Some_Function as:
function Some_Function (...) renames New_Package.Some_Function;

(For compatibility, new programs would use directly the function in the
package).

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

[Robert A Duff]

"J-P. Rosen" <ro...@adalog.fr> writes:

> Le 12/01/2015 01:53, Robert A Duff a écrit :
>> This happened to me: Existing code:
>>
>> function Some_Root_Package.Some_Function(...) return String;
>>
>> Now I happen to know that it always returns String(1..20).
>> And returning known-length strings is more efficient,
>> and this one is a bottleneck, so it's worth changing to
>> something like:
>>
>> subtype String_20 is String(1..20);
>> function Some_Function(...) return String_20;
>>
>> But that doesn't work without adding a new package, which breaks
>> compatibility. And this was a widely-used library, so I couldn't do
>> that. And String_20 really doesn't belong in Some_Root_Package,
>> nor anywhere else than the package that Some_Function is (directly) in
>> (which didn't exist!).
>
> Put the function in a package, and declare Some_Function as:
> function Some_Function (...) renames New_Package.Some_Function;
>
> (For compatibility, new programs would use directly the function in the
> package).

I started to reply, "Good idea", but then I remembered it doesn't work.
A library unit can only rename another library unit. If it did work,
I'd still prefer to use packages from the start.

I see AARM-10.1.1(14.a) explains why we have this restriction, in part
"because they wouldn't be particularly useful". Probably written by
somebody who doesn't like library subprograms. ;-)

- Bob

[Randy Brukardt]

"Robert A Duff" <bob...@shell01.TheWorld.com> wrote in message
news:wcck30s...@shell01.TheWorld.com...
...

> I see AARM-10.1.1(14.a) explains why we have this restriction, in part
> "because they wouldn't be particularly useful". Probably written by
> somebody who doesn't like library subprograms. ;-)

Somebody with the initials RAD? ;-)

Randy.

[Randy Brukardt]

"Robert A Duff" <bob...@shell01.TheWorld.com> wrote in message

news:wcc7fwt...@shell01.TheWorld.com...
...

> Most bug reports are already small. The biggest one I had to
> deal with at AdaCore was about 37,000,000 lines of code.

I think I'm now going to have nightmares about getting a bug report like
that. :-) I fear I get frustrated on reasonable-sized bugs, I don't know if
I'd know how to start with that one. (Of course, I'd probably never get it,
because it would probably exceed the size-limit on something our e-mail
server will accept.)

Randy.