* Re: Some Fundamental Questions on Ada????
1997-09-16 0:00 Some Fundamental Questions on Ada???? Vidanelage Sanath D. Jayasena
1997-09-16 0:00 ` Ralph Paul
@ 1997-09-16 0:00 ` Tom Moran
1 sibling, 0 replies; 3+ messages in thread
From: Tom Moran @ 1997-09-16 0:00 UTC (permalink / raw)
>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.
^ permalink raw reply [flat|nested] 3+ messages in thread