From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_05,MSGID_SHORT
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: 10 Jul 91 22:17:42 GMT
From: cis.ohio-state.edu!magnus.acs.ohio-state.edu!zaphod.mps.ohio-state.edu!ho
bbes.physics.uiowa.edu!ns-mx!pyrite.cs.uiowa.edu@ucbvax.Berkeley.EDU  (Douglas 
W. Jones,201H MLH,3193350740,3193382879)
Subject: Re: Mutual distrust
Message-ID: <6920@ns-mx.uiowa.edu>
List-Id: <comp.lang.ada>

>>From article <EACHUS.91Jul10150645@largo.mitre.org>,
by eachus@largo.mitre.org (Robert I. Eachus):
> 
> 2) Take advantage of the simplifying factor, which allows the following
>     package dependancy to be established...
> 
>     This is the solution I ended up using, but I don't like the assymetry
>     of it, and I don't like what I have to do to it to allow OCCUPANT to
>     return a set of people instead of a single PERSON.
> 
> --       What's the problem? ...

The problem turns out to have been a classic Ada problem -- I was casually
equating the concepts of package and abstract data type.  Someone kindly
pointed this out to me by E-mail, and everything fell into place.

What I did was have the package POPULATION export both PERSON and PEOPLE,
where PEOPLE is an abstract set of PERSON.  The type PEOPLE is quite
handy within POPULATION, it is the type returned by OCCUPANT( PLACE ),
and it is reasonable to implement it by renaming a generic instantiation
of a set or list package within POPULATION.

Making the set of people in a separate package from POPULATION that
depends on POPULATION was clearly wrong, and my casual equation of
package with abstract data type prevented me from seeing that both the
singular and set types should be exported from the same package.

					Doug Jones
					jones@cs.uiowa.edu