eternal civilization foundations

2.18: news.adds/eternal civilization foundations:
openculture introduces longnow.org:
. longnow's Manual for Civilization
aims to select 3,500 books deemed to be
most likely to sustain or rebuild civilization.

spie.org #phy #library

2014.12.12: lib.phy/spie.org/samples:
SPIE the international society for optics and photonics,
is advancing an interdisciplinary approach
to the science and application of light.
SPIE publishes the SPIE Digital Library,
containing more than 400,000 research papers
from the Proceedings of SPIE and the Society's
10 scholarly journals with around 18,000 new papers added each year,
and more than 195 eBooks from the SPIE Press catalog.
The SPIE Press publishes print monographs, tutorial texts,
Field Guides, and reference books.
SPIE also publishes a wide variety of open access content.

ibiblio.org #openware #library

5.8: lib.adds/openware/ibiblio.org:
. textbook on electricity .
Welcome to ibiblio!

ibiblio.org/about
Home to one of the Internet's largest
“collections of collections”,
ibiblio.org is an online public library with
freely available software and information,

the good judgement project

4.2: web.adds/crowdsourcing/the good judgement project:
12.13: summary:
. an arm of the usa goverment is investing in
high-risk, high-payoff research programs;
one of which is the The Good Judgment Project
that harnesses crowd-sourced intelligence
to make predictions about global events.

flatworldknowledge.com's college textbooks #openware

6.1: adds/openware/flatworldknowledge.com's college textbooks:
flatworldknowledge.com's intro for authors:

Who is Flat World Knowledge?:
. it was started by long-time publishing execs
driven by their conviction that the
old model was broken,
and that there was a better way to serve
authors, faculty, and students
based on the open textbook:
it is the same high-quality, peer-reviewed,
professionally edited & developed book,
with supplements such as test banks,
instructor manuals, and lecture slides,
but published under a Creative Commons license:

ratical.org and other libraries

1.6: news.adds/lib/ratical.org:
ratical.org/startHere.html
Today the internet is primarily described as
electronic commerce.
Before 1995 it was lauded as
a so-called information superhighway.
rat haus reality is guided by
the paradigm of web-as-library.
It seeks to implement a collection of
library reference materials
to assist students
in the classroom of life and our world.

10: web.adds/lib/e-books for free:

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:

obj'c categories and Ada's hierarchical pkg

8.14: adda/oop/obj'c categories and ada hierarchical libs:
reviewing:
2012-01-31 Objective-C Categories
1.20: adda/type/obj'c categories:
. Apple is using the obj'c Category for MVC separation;*
eg, string has many uses in a command-line interface,
so it exists in the core package without any methods for
drawing on a gui;
categories are then simply extending that string type,
instead of having sublclasses reuse that string type
in yet another type;
so just one type can exist
yet with  relevant parts in different packages .
* see { Buck, Yacktman}`Cocoa Design Patterns

todo:
. isn't that use of categories needed only because
the designers were assuming certain requirements
that are demanded only by the current oop model?

. if your string wants to express gui-specific tricks
such as appearing in a particular font,
or being arranged so as to follow a curve,
that need should be served by the use of a drawing record
which then has a string as one of it's parts .
(ie, it's ok to have 2 different classes !)
--
. a main point of the book"design patterns

was to critique oop's use of subclassing;
and, that criticism might apply equally well
to this use of categories;
but, generally, categories do have a good purpose:
they allow separate compilation of class extensions
without having to recompile the original interface
which might then require a recompile of
all the clients of that interface .

. this reminds of Ada's hierarchical libraries,
in Ada you can reuse oldlib's module
with the syntax:
package oldlib.additionalmethods
(by including oldlib's name like that
within your new package's name,
your new package includes the binaries of oldlib ).
. now current clients of oldlib
still don't have additional methods,
but, future clients of oldlib.additionalmethods
will have access to both modules
with that one import .
. obj'c categories by contrast,
allow you to add the same new modules
but this addition will also be affecting
current clients!
-- the category's method has access only to
the target's interface, not its internals;
so, a category can't fix every bug;
yet it can create bugs because it can
override system methods .

. I have 2 competing ideas on this:
# we should be able to describe in adda
any idea of any other language;
vs,
# we should not be supporting the use of ideas
that are either complicating or insecure .

here's how the the Category idea might be impl'd:
. when a datataype agrees to be modified by categories;
then at run-time, the type mgt is a modifiable object
and, it provides a dictionary
where you can see if it supports a message .
. it can dynamically add entries to this dictionary
(allowing it to support new messages),
and it can change method addresses
(allowing it to update the methods of old messages).
[10.8:
. now all we need is an uncomplicated way to
decide which types are so modifiable .
. perhaps a type wishing to participate
could declare one of its components to be
a dictionary with a standard name
(perhaps SEL, in honor of Obj'C);
then anytime a message is unrecognized,
the run-time would check SEL for the method .
11.8: correction:
. in order to work like an obj'c category,
it has to check SEL all the time,
not just when a message is unrecognized,
in case one of its methods got overridden .]

an intuitive library

7.19: addx/library/an intuitive library:
. how do we equate the contents of adda's lib
with some sort of filesystem structure?
. are library units placed in a lib folder?
is this done by declaring the unit's name to be
libName/unitName?
how can things be more implicit or intuitive?
. when you write interactively
this is being stored as a folder called
interactive.adda .
. each folder named x.adda, for any x,
is a separate adda acct
meaning it's a top-level lib .
. it had been previously proposted that
naming a file or folder x.adda
would indicate the contents was text
that conformed to the adda language;
. the current idea differs slightly:
the folder named *.adda would mean that
all the files and folders inside
would have names like x.t,
where t would be some adda typename .
. the x.adda folder also lets the files inside
have names like x.t.txt
so that if you want to use
other tools to open the files,
these tools know a .txt is ascii or utf-8 .

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

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 . 

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 .

center for economic literacy

11.24: web.adds/center for economic literacy:

. Powell Center for Economic Literacy is a resource for teachers and students

with lesson plans, and curricula for economics,

and information on learning opportunities in the field of economics.

see alsowww.infusionomics.com/

for aspect-inversion: integrating economics lessons into other fields .