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:

t.type/newlib`=(..),

t.type/newlib`body`=(..),

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 .

95:

. the includes go in a jacks.folder ? .