hierarchical modules

8.30: adda/ada`module architecture:
. instead of private part in head
they mean the head is a public contract
and part of the body can include a contract also .

. if types aren't defined in head,
compiler expects them def'd in body`root

8.30: adda/syntax/hierarchical modules:
unlike ada,
using the type t auto'ly makes all of lib available .

9.4: adda/import/as folder structure:
. the primary way to do implicit import
is to declare a var to be a type,
and then that type's module is imported .
. but what about other modules?
. the most intuitive way of importing
is to put the pkg's or their links into the program's enclosing folder,
. instead of putting the pkg itself there,
there would be an interface file .
that way, if the program is moved to a new user,
instead of just importing the name of a package,
you have the package's complete socket description;
making it harder for mix-up's to happen .
. this could still be done using ada's style:
"(import pkg) would make sure there was such a pkg header,
and copy it to the program's enviro.folder .
. the project folder contains a subfolder for each library unit;
. a subprogram has a separate folder that contains
separate parts of the program:
file for code
files or links for pkg heads,
subfolders for each local subprogram .
. here is the intuitive import:
"(../`+ my.pkg)
. it reminds you there is correspondence between the program structure
and some of your folder structure .
. you can do this by hand,
then go into the header and weed-out all the entries
that your program won't be using .
. the includes go in a jacks.folder ? .