adda`lib folder system

1.15: mis.adda/cstr/pkg/how do packages work?/
adda`lib folder system:
. I seemed to have missed the point of
de-anonymizing a type:

scriptability with sandboxing

6.30: addx/scriptability with sandboxing:

. I was surprised to learn that Preview
-- one of Apple's own apps -- is unscriptable;
but, perhaps that's because it's so costly to produce
the needed scripting dictionary .
. one of addx's motivating features
was the pervasive use of the MVC pattern;
with that in place, app's always come in 2 parts:
# the model that can talk to any controller
(because it's a command line tool);
# the gui controller that humans will need
in order to interact with the model .
. the scripting dictionary comes free
(without the developer having to do anything)
because in order to get an app installed in the system
it had to be submitted to the system librarian,
who put the model's specification in the library
which is viewable by humans and controllers alike .

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 .]

library mgr preparing code for export to public

3.23: adda/library mgt/preparing code for export to public:
. should adda use the python module system?
. the problem python has is a rapidly changing system library;
often times the system will choose the same name as
some private user modules,
so unless you have separate namespaces for {system, user}
the system space will likely engulf part of existing user space,
thereby changing the meaning of some older programs,
at least if user's upgrade their system library .
. the library mgt should take care of this:
when you upgrade the system,
it tells you whether the new system is clashing with your library .
. if you export your code for public use,
it makes sure that your references to local modules
include the url where that module's source code is kept .
. if there is no url, or you modified the code,
then the library makes sure your export
includes the local source code .
. the export also needs to indicate
the current version of the system module
so then when a library mgr is importing a module
it has to find a compatable system to place the new module;
and it has to check for library conflicts,
where the current compatible system
has the same names as some of the modules being imported,
in which case it has to rename the user modules,
and patch all references .

symbol table linking

7.14: 7.15: adda/symbol table linking:

. etrees (expression trees)
are tree nodes with pointers into
global and local dictionaries of symbols
(symbol tables).
. every etree module
implies access to a global symbol table,
and must specify any needed local symbol tables .
. there can be more than one local symbol table;
because, a dictionary can include procedures;
and, procedure definitions can have
local dictionaries:
the parent procedure becomes the
scope of its local dictionary,
hence the term "(nested scopes),
involving stacks of local symbol tables .
. each module has a tree of symbol tables .
. a typical scope path is:
module/subprog/nested sub/nested block/nested block .

. the 3 main uses of "(library) include
system, standard, and custom .
. the system library of an addx installation
is a service for organizing and linking
the modules that are available for reuse .
. a standard library is a module that is
declared by the system's language .
. a custom library is one added by the user .
. each module has a list of imported modules,
and a tree of symbol tables
to match its tree of nested scopes .

. when designing the pointer that is
going from etree nodes into symbol tables,
there must be an efficient coding,
and it should support efficient copying
even when it involves context changes
(re: adde/object copy & paste).

etree node variants for library symbols:
. there is first a bit to distinguish
symbol location type in {library, local}:
# library location:
. there may be many libraries in use (15-bit),
and many symbols per library (16-bit) .
# local location:
. there's often no more than
4 nested levels of locals (2bit);
and often less than 256 symbols per local (8bit).
but if node`size is in increments of 16bit chunks
that division could be 4 bits for 16 nested scopes,
and an 11-bit space for locals,
or less if the descriminant is more than 1 bit .
[7.30:
... in any case, the more space you save,
the less efficient it is to remap etree nodes
to a new symbol table after a context change .]

details of library location:
. there could be an infinity of libraries over time,
so the library codes in an etree node
don't represent specific libraries,
rather they represent a slot in the module's
list of imported or required libraries;
however, standard libraries can be specified,
since there are a finite number of them;
ie, if the code is in the range that is
reserved for standard lib's,
then that is the same code used by
the system library;
otherwise, we need to use the module's import list
to convert the symbol table's code
into one that the system library recognizes .

. the system library creates a custom lib's code
by taking a Secure Hash of its interface
. as long as that didn't change,
it would be considered the same library . 

library mgt

11.9: adda/lib mgt/multiple lib's:

. a lib is an obj file that does lib mgt;
you declare it in a folder,
and then anything compiled from within that folder
is registered in and by that lib,
if a project folder doesn't have a lib,
the compiler searches up the folder hierarchy,
and beyond the acct's db:
the node's lib, intranet's lib,
and finally the std, built into the compiler .
. at each level, a diff shows
how your lib is a modification of
the lib it inherits from .

. lib's can easily share items with other lib's:
their items are just links to the acct's db,
modified entries simply switch the link
from targeting the share
to that of a private lib .

. adda assumes you want a lib
placed in the top of your acct`fs (your home dir)
-- with no localized lib's,
and all compilation units shared .

. if you want to make sure you don't
link to anything except locals;
create a new empty lib in your project folder,
and inherit null .

. you can inherit from another lib
either by copy or link:
(linking to the lib means your lib
grows with that lib,
copying means you copy all the current items)
. various ways of partial inheritance:
# undo some of an inheritance
# inherit specific components of a lib .

foreign lib heads-up wrapper:
. program's compiled by adda are
user-friendly because all code is
sprinkled with embedded calls to gui mgt
for ensured responsiveness .
. since adda language is translated to ansi c,
it can link to foreign lib's
(ones that adda didn't compile).
. adda puts a wrapper around
calls to foreign code,
reminding  the user that
some potentially intrusive code
is about to run,
the reminder would have some option checkboxes:
# ok to always proceed without warning?
# for any foreign lib?, whitelist... warnlist... .
# want a dashboard light indicating
when the system is running foreign code? .

. if there's some way to know
when the user is annoyed,
and it may be due to the system being unresponsive,
that will never happen when addx is running adda code,
so then remind them it's because
a given foreign function is not releasing control .

. one way to insure more integration
is by being able to insert gui-relief calls
at the c code level,
rather than in adda code .
11.12:
. but that still leaves code that can't be trusted;
it is impossible to convert arbitrary c
to safe c, in every case,
because the arbitrary c wants to do things
that safe c would never do!
but, adda should at least attempt it,
at least in some advanced version;
otherwise,
. adda should tell the user
when a foreign lib can't be coverted by adda,
and explain why adda generates c code,
rather than reusing c code:
it's more trustworthy even if not more efficient;
because, it's sure not to crash the app,
and not have vulnerabilities that could be
used by malware seeking to smash the stack or heap .
11.11:
. when users add a foreign lib to their acct,
they should be reminded of the risks,
and should identify the source
with a {project name, url, author name}
so that if there are problems with it,
addx can meaningfully show users
which lib is involved .

dependency versioning

7.10: adda/lib'mgt/dependency versioning:

[7.27: summary:
. these are rough ideas for
how to keep a library of software components
modifiable and evolvable,
without having problems with version conflicts .]

. intro to versions conflicting with portability:

"(
Forth was interesting in that
not only it was written in itself,
but all the internals were available
to any programs written in it,
and, furthermore, could be changed at will.
The thing is, Forth lacked abstraction.
Yes, you could change the compiler.
But, of course, you’d have to know
how the specific compiler worked:
eg, for threaded code, variants included:
generated {indirectly, directly, subrouting},
and generated {bytecode, machine coded}.
So it had no portability at all.
)

--. that inspired these ideas:

. in addition to there being
versions for systems;
any component that allows being changed,
must have it's own version number
for both the spec' or interface changes,
and the impl' or build changes .
. if the author (ie, the name of a fork)
is not specified with the version number;
then it's assumed to be from the main source .

. to be portable with forks,
the original site must provide
version numbers for
all components, and all forks .

. in order for a fork to use
the original project's name,
it must subscribe to the original's
versioning protocol:
a component lists its dependencies
which includes the release version
of a particular fork
modified with the release versions
for particular components .

. that means when a library or app
is introduced to a platform's lib mgt,
it gives the expected release versions:
this is described economically by saying
most components' versions are that of
some author's system release;
while a few components vary from that release,
and are described individually .
. the lib'mgt then checks these dependencies,
and tries to procure them if not present .

. the user should also be notified
when an installation has
many unique dependencies;
at least if the practical size
is significantly larger
than the app's stated size .

. each version requires its own
space in the library,
along with pointers to
whatever other units are using it;
so then, if you uninstall a unit,
all its bloat goes with it,
unless a dependency is still used
by other units .