libraries and namespaces

6.14: adda/library/authors include system, app, client:

. Python has 2 libraries to choose from:
standard and local .
. Ada has one library with any number of modules,
including standard.package .
. instead of ada's one library,
there should be 3 libraries, one for each author:
system-authored -- the standard modules;
app-authored -- the software developer;
client-authored -- the user of the app .

. libraries can be specified by the app author,
(system is adda/aModule, local is ~/aModule )
but specifying this is not necessary because
the app's local library is always checked first;
ie, if an app author wants to use a system module
they simply abstain from giving any local modules
the same name as the needed system module .

. module providers can define
what other authors they want used
and in what order .
. notice that while many commercial wares
are arranged by author,
many openwares are arranged by project;
ie, each project represents an author collective;
but these collectives then have branches
which might represent either author subsets
or target-specific variations;
so, the typical explicit local path will be:
~/myProject/myBranch/myModule .

6.15:
. the client's library can have subfolders for
each of the authors: system and each app .
. the compiler always gives the client the final say,
so that if the users want to modify (system/x.pkg)
they write their own in (client/system/x.pkg).
. if the author requires that they not be modified
then a commercial version of the compiler
would alert the user that their modification
is being ignored due to contractual obligations .
. in the open-only version of the compiler,
the user would be unable to install commercial wares .

6.18: adda/library/hierarchical librarians:
. we could also have the idea of hierarchical librarians;
ie, just as the typical librarian is local to the file system,
rather than applying to the entire local network
or to the entire internet,
so also, a librarian could be local to a folder .
6.19:
x : dir-name/type-name
. what was the library structure defined by ? ...

6.14: adda/type/record expressions vs literals:

. being required to statically type vars
is not a loss of freedom because
we can declare a var to be tall.type,
which means it may include any type
(tall typings are like tall tales,
leading t'all sorts of things ...).

. what should the import syntax be?
my first idea was that explicit importing was mostly unneeded,
because by typing var's,
we implicitly import that type's module;
but there are other types of modules to reuse .

. think of the orthogality:
when defining var's in a name space,
these are actually fields in a record literal;
. just as data types may define both literal values
and expressions that return values;
so too we should be able to define record structures
with either literals or expressions .
. ada uses {with, use} for expressing this .

. a situation similar to importing is inheritance
so importing should have the same syntax .
. a recent proposal for such syntax was
(3.23: adda/oop/syntax/sections for use, is, has).
. it suggested 3 new keywords:
# use:
. for an interface to import a module;
they may refer to types other than self
that are not in the top-level library .
[6.15:
. here's all the places a type's name can get reused:
app's pkg, pkg's of other authors being imported
wanting a system type
even though app has redefined that type name
in one of its own local modules .]
# is:
. for supertypes,
establishing type compatibility .
# has:
. for listing the type's known subtypes;
eg, number.type has all of these subtypes:
int, real, quotient, complex, modular .

. I thought a good word for "(import) was "(has),
but if possible I should make sure that
the keywords have similar meanings
when used by inheritance and namespace definition .

7.2: todo:
. I need to show the diff's and similarities
of inheritance to namespace definitions .

6.15: adda/library/anonymous record declarations:

. why not do imports by declaring records globally,
and then instantiating records?
and instead of (with; use),
do an anonymous instantiation;
ie, instead of (x.myrec), say  (.myrec)?
but if we have multiple anonymous record declarations
with conflicting component names,
we have no way to resolve the conflict
because we have no root name to specify .
[6.19:
. we could use the type name as a root,
and use either record instances or rec'types .
. rename is done like this (x: mypkg)
while using original name is (: mypkg)
and if conflict use (mypkg.component).
. anything on the right side of colon must be a
library item, either an instance or a type .
. might be easier on the reader's eye if we
always required renaming when importing rec'instance .

. should we always have an implicit ada'use in force
for if a naming contention exists ?
here's the reason ada'use is optional:
it is filling the name space;
and, these included names can't be redefined now;
better to use ada'use the way ada uses it .]

. Ada's packages are like record instances
-- in contrast to record types;
Ada'with(package) allows the instance to be
visible to the current scope .
. packages in the Ada library may include variables
(this is how Ada can define global variables).
. by being instances instead of record types,
the included variables are being shared by
every process that includes such a package,
ie, a global record instance .

. subrograms are types not instances;
when we have a pointer to a function
what we have is a constant template
which can be shared by numerous
function activation records,
just as numerous record instances
share the metadata of a record type
that is in control of record instance formatting .
. thus, a function activation requires a pair:
(the name of the subprogram providing the template,
and the address of an activation record);
when we speak of a process,
this pair is what we're refering to;
(6.17:
but when concurrency is considered,
then a process implies a triple:
the 3rd component of this triple is a
thread of execution:
either the id of the processor it is using,
or a task mgt record
for controlling a slice of the processor's time ).

. global variable instances can be confusingly shared by
many authors' processes;
so, a global variable should be registering
which processes are using it,
and be able to tell us which processes have been involved;
likewise, any subprogram that can
spawn tasks which can share its local var's,
creates a situation where processes share a var
but this is not so confusing because
it doesn't involve sharing among various authors .
[6.16:
. the way globals are shared by various authors
can also be happening locally,
if we can import a package that expects
the eviron to provide a sharable var .
[6.18:
. but maybe this should not be happening;
if you want an import to use your locals
it should exist as parameterized record type,
so then a parameter used during record instantiation
is passed the address of locals it can use .
... or how about this:
. when a type is instantiated by a client,
in addition to allocating an instance,
it also gets some sharing space in client
which the type mgt can use for keeping
meta info or parameters
that are relevant to just a particular client's set of
a particular type's instances .
. this new space would be similar to class var's,
except that instead of being shared by all members of the class,
they would be shared only by those members
that were owned by a particular client
ie, contained in a particular subprogram activation record
or a declare block .
. so then, if type mgt's can do this,
instantiated records could also .]

. other confusions with what's global include
# the internet is the top-most global,
# one's local network is global to a file system .

. we can think of global var's as
implicitely inheriting from registering
(no process can access the registering type
without getting registered).
. if we want registering behavior for a local
we must explicitly have it inherit from registering .

. my initial concern with vars being shared
could only happen because the author put the var there,
but there could still be surprises among an author's subprograms
because the author's client can choose to
run more than one of the author's sub's at a time .
. an imported sub' should be able to
declare a non-local var as a dependency
in order to have symmetry with the idea that
subs can access non-local vars;
and,
that feature should be orthogonal to
the feature of a sub being reusable .]