Structure of Ada Programs

Structure of Ada Programs Building a program from components Programming LanguagesFall 2003

Structure of a Program • A program is a collection of separately compiled units • One unit is a distinguished main procedure • The units must be bound together to form an executable program • The binder checks for type consistency and elaboration order consistency.

Units 1 (Subprograms) • A unit can be a stand alone function or procedure. • Such a unit may or may not have a separate spec (which is a separate unit) • Generally good to have this separate spec since it means recompiling body does not require clients to be recompiled

Units 2 (Package Specs) • A library package is a collection of declarations of types, (global) variables, and subprogram specs. • Package x is declarationsend x; • If any subprogram specs present, then there must be a corresponding body

Units 3 (Package bodies) • A package body contains the bodies of all subprograms whose spec is in the package spec. • It can also contain local subprograms (with or without separate specs) that can only be called within the body. • It can also have local types, variables etc • A package body variable is the equivalent of a static variable in a C function.

Private Sections in Packages • A package can have a private part • package Stuff is public declarations …private private declarationsend Stuff

Private Part • Must contain full declarations of any private typese.g. type Name is privatethen in private part type Name is new String (1 .. 20);

Private Parts (continued) • Must contain declarations of any deferred constants type Set is private; Empty_Set : constant Set;private type Set is array (integer range<>) of Integer; Empty_Set : constant Set := (1 .. 0 => 0);

Private Parts • Can contain any other declarations (types, variables, subprograms). • These declarations can be referenced in the body (but they could be in the body anyway in that case) • But can also be referenced in child packages.

Child Packages • Can be used to extend a package in a hierarchical mannerpackage Calendar is ….package Calendar.Alarms is … declarations extending Calendarend Calendar.Alarms;

Child Packages • The child can see all declarations of the parent (without a WITH clause, since it is really part of the parent). • The private part and the body of the child can see the private part (but not the body) of the parent.

Clients of Child Packages • A client can see just the parent’s declarations: with Calendar; package Client is … • Or it can see any or all of its children with Calendar; with Calendar.Alarms; package Client is …

Private Packages • A private child package private package Calendar.Internal is … • Can only be with’ed by other children of Calendar. It allows separation of functions into a separate package without exporting the outside the hierarchy.

Bottom Up Program Structure • From primitives, build larger abstractions,in the form of reusable packages. • These reusable packages can be used to build higher level abstractions. • Eventually the level of abstraction (and power) is sufficient to allow the program to be written as a single main program that makes appropriate calls.

Top Down Structure • We write the entire program, but leave sections for which we fill in the detail later. • Then we write these sections, if necessary leaving sections of them in turn to be filled in later. • We continue until we can write the sections directly in terms of available primitives.

Subprogram Subunits • procedure Main is Data : array …. procedure Input; procedure Calc; procedure Output; procedure Input is separate; procedure Calc is separate; procedure Output is separate;begin Input; Calc; Output;end;

Filling in the Details • Now we provide separate subunitsseparate (Main)procedure Calc is …end; • Note that procedure Calc has full visibility of its environment (e.g. can access Data, or call Output or Input).

Package Subunits • package body Sets is type Set_Implementation is …. … package Set_Utilities is procedure Q; … end Utilities; package body Set_Utilities is separate;end Client;

Filling in the details • The package body subunit is a separately compiled unit:separate (Sets)package body Set_Utilities is procedure Q is … end Q; …end Set_Utilities; • Again, the subunit inherits its context (and can for example reference type Set_Implementation;

Generic Units • A library unit can be a generic unit • Generic subprograms • Generic packages • Generic children of generic packages • Can instantiate at library level to make a usable unit, e.g. with Text_IO; package Int_IO is new Integer_IO (Integer); • Or can instantiate within another unit

Main Program • Typically a parameterless procedure • Can be a child procedure of a package • Can also be a function (input arguments might be argv/argc style command parameters, result might be return code) • Binder is told main program, and creates the transitive closure of all units with’ed verifying consistency.

Distributed Programs • Another step (Annex E of reference manual). • A program is a collection of partitions • Each partition is essentially what we have called a program so far • Partitions can communicate with remote procedure calls • Consistency is checked

Building an abstraction (card games) • package Cards is type Rank is range (‘2’, ‘3’ ,’4’… Jack, Queen, King, Ace); type Suit is (Clubs, Hearts, Diamonds, Spades); type Card is record R : Rank; S : Suit; end record; -- We decided to make card a non-private type so -- that we have aggregate notation as in: -- -- Face_Card : Card := (King, Spades); -- -- If we made it private then we would have to write -- -- Face_Card : Card := Make_Card (King, Spades);

Building an abstraction (card games) • We decide to make Dec private type Deck is private; • Subprograms operating on Decks: function Empty_Deck return Deck; function Full_Deck return Deck; procedure Shuffle (D : in out Deck); procedure Put (C : Card; D : in out Deck); procedure Remove (C : Card; D : in out Deck); • An exception raised if card to be removed is not in deck Not_There : exception;end Cards;

A child Package for Display • package Cards.Graphics is type Size is (Small, Medium, Large); type Location is record X, Y : Float range 0.0 .. 10.0; end record; procedure Display_Face_Up (C : Card; P : Position; S : Size := Medium); …end Cards.Graphics;

Playing Klondike • with Cards; with Cards.Graphics;package Klondike is type Column is range 1 .. 7; procedure Deal_Tableau; function Top_Card return Card; procedure Flip; procedure Place (C : Card; Col : Column); procedure Move_Col (From, To : Column); Illegal_Move exception; Win, Lose : exception; …end Klondike;

A main program • with Klondike;with Cards;with Text_IO; use Text_IO;procedure Main is procedure Play; procedure Play is separate;begin Klondike.Deal_Tableau; Play;exception when Win => Put_Line (“won!!!”); when Loose => Put_Line (“lost!”);end Main;

The actual playing algorithm • The actual playing algorithm is a subprogram subunit:separate (Main)procedure Play is …end; • Note that this Play routine has full access to the facilities of Klondike and Cards

Structure of Ada Programs