The ACE programming language support the kind of abstraction refered to as process abstraction, as most programming languages do. Process abstraction is when we use subprograms to provide a way to tell the compiler that something has to be done, without exactly saying what (at least, not within the calling program or subprogram).
The ACE programming language also supports encapsulation, or the grouping of subprograms and the data they manipulate. An ACE program can be made up of several unique modules. These unique modules can be found in external files. Each external file looks like this:
**********************************************************************************
"name".ACE
LINK "name2".ACE, "name3".ACE, etc.
{declarations and definitions of functions and variables}
BODY:
{actual program}
END BODY.
**********************************************************************************
"Name" is the name of the file. The .ACE extension is not optional. An ACE compiler will not accept a module of an external file unless that module has the .ACE extension in its name.
LINK is the command that links other ACE files together. An ACE program that concerns itself with the solving of certian equations of a certian form may have need to call another ACE module that is designed to deal with matrices, for example. In order to call a function in that file or module, the file must be "linked" prior to calling by the link command. It tells the compiler where to look for functions if they aren't found in the module that called them.
Declarations are made and procedures can be defined prior to the body of the program. A module could concievably contain just a set of procedures. It doesn't have to have a program body within it. Also, for another module to be able to access or use functions or variables within the module, the keyword "public" must be put in front the declaration/definition. See our example below for details.
The program body is optional; a module might actually contain a full program that could be called by another programmed linked to that module. If a module has a body, then when any function within the module is called, the body is executed. For instance, suppose I write an ACE program to display the contents of a graph. One module might handle common graph tasks. This module would have procedures written for displaying the graph of an equation, displaying the derivative of the equation, etc. Each time one of these functions is called, a graph needs to be displayed on the screen. The body of the module could be written to set up and display a set of axes and coordinate plane, and this body is executed every time any function within this module is called. That way, each time a function dealing with a graph is called, the body sets up a new set of axes for that function to work with.
Here is an actual, simple module as would be used by an ACE programmer:
**********************************************************************************
EXAMPLE.ACE
LINK STUFF.ACE, STUFF2.ACE.
PUBLIC SUB DO_SOMETHING ( INT A, INT B, INT C)
BEGIN:
A=A+B+C;
END.
SUB DO_SOMETHING_ELSE (INT A, INT B, INT C)
BEGIN:
B=STUFF.DO_STUFF(A, B, C);
END.
BODY:
INT B=DO_SOMETHING_ELSE(2, 3, 4);
STUFF2.DO_MORE_STUFF(B);
END BODY;
**********************************************************************************
In this example, our module is called EXAMPLE.ACE. Any other module could call EXAMPLE's function DO_SOMETHING (provided the calling module was linked to EXAMPLE). Only procedures within EXAMPLE could call DO_SOMETHING_ELSE. Since EXAMPLE is linked to STUFF and STUFF2, EXAMPLE can call upon STUFF and STUFF2's public functions. A function within the module is refered to by the name of the module, followed by a period, followed by the function name. Also, whenever any function in EXAMPLE is called, the body is executed first.
These files are like abstract data files in the sense that other files don't get to see or use internal features of these files unless the internal features are declared public. Anything not declared public is considered hidden.
These modules, however, are NOT abstract data types. These modules/files aren't "types"...you can't declare an object in ACE of type module or file. So, in other words, ACE does not support abstract data types. Why not? Because ACE is a mathematical language, and most data being manipulated in an ACE program will be of a primitive data type (with the exception of our arrays). There is no need for the user to be able to create his/her own type, with functions associated with that type. There should be no mathematical call for it.