Need advice re package organization.

["Bobby D. Bryant" <bdbryant@mail.utexas.edu>]

Most of my work with Ada has involved either smallish programs or simple
self-contained library units where a good package organization was
obvious, but now I'm doing something with several layers of interrelated
parts and I'd like to get some experienced advice on how to organize my
components into packages.

For the (n+1)th revision of my research code I'm going to break up my
neural network implementation into a hierarchy of objects, not a
derivational hierarchy but a hierarchy of objects composed from more
elementary objects.  In particular I'll start with some atomic types for
weights, activation accumulators, etc., implement neurons as compositions
of those atomic types, layers as compositions of neurons, and networks as
compositions of layers.  Each component will have various utility
procedures and functions in addition to the type definitions, and most of
the types will be tagged types to facilitate the creation of derived types
for instrumenting the behavior of individual objects and some other odd
things I do in my research.

The intent of that component design is to allow programs or auxiliary
packages to manipulate networks as high-level abstractions, but to be able
to reach down and manipulate a layer or a neuron directly when necessary.
My question is how would be the best way to translate that structural
hierarchy into Ada packages.  Three obvious solutions come to mind:

1) Roll everything into a single package.

2) Create an independent package for each level of the hierarchy,
"with"ing the other packages as needed.

3) Create a lean parent package and implement each object in a separate
child package, "with"ing the others as needed.

The third does not seem a very obvious solution to me, but I'm considering
it because that's generally how GtkAda is organized.  However, the
hierarchy flattened by the GtkAda package structure is more a derivational
hierarchy than a compositional hierarchy, so I don't know whether the same
design considerations would apply.

Any suggestions, either for my specific example or for more general
considerations?

Thanks,

-- 
Bobby Bryant
Austin, Texas