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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,3092a8c485ee9d0e
X-Google-Attributes: gid103376,public
From: tmoran@bix.com (Tom Moran)
Subject: Re: Some Fundamental Questions on Ada????
Date: 1997/09/16
Message-ID: <341eb65e.2336180@SantaClara01.news.InterNex.Net>#1/1
X-Deja-AN: 273011130
References: <341EAFD4.5D8C@cs.uiuc.edu>
Organization: InterNex Information Services 1-800-595-3333
Newsgroups: comp.lang.ada
Date: 1997-09-16T00:00:00+00:00
List-Id: <comp.lang.ada>


>1.1 What is a 'module' in an Ada (software) system ?
>    Is it equivalent to functions/procedures in Pascal/C
>    languages ? 
>    (But I heard that Ada has procedures as well.)

>1.2 What are 'packages' and 'tasks' ? 
>    How are they related/connected to 'modules'/'procedures' ?
>   
>2. Can several 'procedures' exist in one 'module' ?
  An Ada 'package' can contain procedures, functions, variables,
constants, etc.  Normally a package will contain the things relevant
to a single concept, eg, a package containing a set of trig functions,
a package containing the data and procedures for a symbol table, etc.

A task is a separate thread of control, (conceptually at least)
running simultaneously with other tasks.  A simple program has but one
task, while a more complex one might have several.  A task, like a
procedure, is declared in some package, but it may certainly call
procedures in another package (eg, a task to control a robot's arm
movements in real time might call functions in a trig package).

>3. Can there be inter-module calls (just as we have
>   inter-procedure calls in other languages) ?
>   If so, are parameters passed ?

>4. What about inter-procedure calls ?
>   Can they be inter-module or should they
>   always be intra-module ?
>   
  Suppose there is a package Trig, which contains, among other things,
a function Sin.  Further suppose a package Simulate_Billiard_Motions
contains a procedure Calculate_Bounce, which needs to know the sine of
an angle. It would then contain a line like:
      X := Trig.Sin(Theta);
That would be a call from a procedure in one package to a function in
another.  The parameter(s), if any, would depend on the particular
procedures or functions called. Thus a package doesn't call another
package, but a procedure in one package can call a procedure in
another. 

 If this whole program was very small, it could be entirely contained
in a single package, but it's generally much simpler if something like
Trig is a separate package, separately maintained and updated with
newer and faster algorithms.  Since the public view of the Sin etc
routines is unchanged,  the Simulate_Billiards_Motion package would
not need to be changed. 

Since Calculate_Bounce, on the other hand, should not be called except
by other routines inside package Simulate_Billiard_Motion, it would
probably be put in the non-public part of Simulate_Billiard_Motion,
thus preventing it from being called (erroneously, or without other
necessary related calls) from any other package.   

Usually an Ada package will consist of two files: a specification part
(eg, that lists, in the case of package Trig, Sin and tells its
parameters and what it returns), and a body which contains the actual
implementing code.  If the packages are very small and closely
related, then several packages may be put one after the other in a
single file.  If a single package is very big, there are of course
ways to break it up into pieces in multiple files.