1086 O-O PROGRAMMING AND ADA $33.4 grossly violating the underlying abstract data type specification. Conceptually,the type declarations belong in the body.Why did we not put them there in the first place?The explanation requires that we look,beyond the language,at programming environment issues. One requirement on the Ada design,already mentioned,was that it should be possible to compile packages separately and,moreover,to compile a client of any package A as soon as you have access to the interface of 4,but not necessarily to its body.This favors top-down design:to proceed with the work on a module,it suffices to know the specification of the facilities it needs;actual implementations may be provided only later. So if you have access to the interface of REAL STACKS (that is to say,the interface of STACKS,of which REAL STACKS is just a generic derivation)you must be able to compile one of its clients.Such a client will contain declarations of the form use REAL STACKS 1;... s1,s2:STACK,… s2:=s: which the poor compiler cannot properly handle unless it knows what size is taken up by an object of type STACK.But that can only be determined from the type declarations for STACK and the auxiliary type STACK CONTENTS. Hence the dilemma that faced the designers of Ada:conceptually,such declarations belong to the inferno-the body;but implementation concerns seem to require their inclusion in the paradise-the interface. The solution retained was to create a purgatory:a special section of the package that is physically tied to the interface,and compiled with it,but marked in such a way that clients may not refer to its elements.The purgatory section is called the private part of the interface;it is introduced by the keyword private (also used,as we saw above,as a qualifier for protected types).Any declaration appearing in the private part is unavailable to clients.This scheme is illustrated by our final version of the stack package interface: generic type G is private; package STACKS is type STACK(capacity:POSITIVE)is private; procedure put (x:in G;s:in out STACK); procedure remove (s:in out STACK): function item (s:STACK)return G; function empty (s:STACK)return BOOLEAN; Overflow,Underflow:EXCEPTION:1086 O-O PROGRAMMING AND ADA §33.4 grossly violating the underlying abstract data type specification. Conceptually, the type declarations belong in the body. Why did we not put them there in the first place? The explanation requires that we look, beyond the language, at programming environment issues. One requirement on the Ada design, already mentioned, was that it should be possible to compile packages separately and, moreover, to compile a client of any package A as soon as you have access to the interface of A, but not necessarily to its body. This favors top-down design: to proceed with the work on a module, it suffices to know the specification of the facilities it needs; actual implementations may be provided only later. So if you have access to the interface of REAL_STACKS_1 (that is to say, the interface of STACKS, of which REAL_STACKS_1 is just a generic derivation) you must be able to compile one of its clients. Such a client will contain declarations of the form use REAL_STACKS_1;… s1, s2: STACK; … s2 := s1; which the poor compiler cannot properly handle unless it knows what size is taken up by an object of type STACK. But that can only be determined from the type declarations for STACK and the auxiliary type STACK_CONTENTS. Hence the dilemma that faced the designers of Ada: conceptually, such declarations belong to the inferno — the body; but implementation concerns seem to require their inclusion in the paradise — the interface. The solution retained was to create a purgatory: a special section of the package that is physically tied to the interface, and compiled with it, but marked in such a way that clients may not refer to its elements. The purgatory section is called the private part of the interface; it is introduced by the keyword private (also used, as we saw above, as a qualifier for protected types). Any declaration appearing in the private part is unavailable to clients. This scheme is illustrated by our final version of the stack package interface: generic type G is private; package STACKS is type STACK (capacity: POSITIVE) is private; procedure put (x: in G; s: in out STACK); procedure remove (s: in out STACK); function item (s: STACK) return G; function empty (s: STACK) return BOOLEAN; Overflow, Underflow: EXCEPTION;