ROPE: TYPE = Rope.ROPE;

STREAM: TYPE = IO.STREAM;

Object: TYPE = MathObjects.Object;

MethodDictionary: TYPE = MathObjects.MethodDictionary;

A (Math)Package is simply a collection of procedures that operate either on Cedar entities or MathObjects, the latter typically elements of Domains or Views. Packages differ from (Math)Structures in that they do not model mathematical structures, i.e. they do not name any "underlying set" or "collection of elements", but simply comprise procs.

The implementation of a Package may, however, model Domain implementation, e.g. store and provide access to its component procedures via a MethodDictionary.

Package: TYPE = Object;

PackageData: TYPE ~ REF PackageDataRep;

PackageDataRep: TYPE;

The .class of a Package is the SystemObject Packages, whose .data records (and defines, implicitly or explicitly, a search order for) all currently known Packages, and provides methods for performing such searches.

Its .methods provides methods for access to the constituents of its Elements (i.e. Packages), e.g. search, a $flavor method (returns $Package), and an $eltDisplay method.

Packages could be regarded as a Domain, but there seems no mileage in this.

Packages: Object;

PackagesData: TYPE ~ REF PackagesDataRep;

PackagesDataRep: TYPE; -- Can perhaps include a RedBlackTree of known Packages, to capture a linear order for package searching in method lookup (although this role could be supplanted by the convention that Packages are only known ("registered") in some MathEnvironment). If that convention not adopted, PackagesData should also include access to Methods for "enumerate current Packages", " LookupMethodInPackage", etc.