survey of programming architectures

11.15: web.adda/oop/architectures:

the categories of inheritance:

# type clustering (inclusion polymorphism):

. numbers are the classic type cluster;
that type's major subtypes have overlapping interfaces;
and they need a supertype to coordinate biop's
(binary operations; a function with 2 arg's;
eg, addition's signature is: +:NxN->N )
whenever the param's have unmatched subtypes
(eg, RxC->C, ZxN->Z, /:NxN->Q, ...).

type cluster/supervision models:
. the set of polymorphic subtypes is fixed,
and the supertype knows how to convert between them;
it knows the data formats of all its subtypes .
# translated:
. the supertype provides an all-inclusive
universal data format;
eg, numbers -> complex .
. all subtypes convert between that format
and their own .

type cluster/subtypes must include range constraints:
. range constraints are essential for efficiency
as well as stronger static typing;
because, range limits are what allow
direct use of native numeric types .
. typical native types include
{N,Z,R}{8,16,32,64,128} .

# type classing (Subtype polymorphism):
. declaring a type is a member of a class,
and is compatable with that class
by inheriting its interface;
the new type is then usable
anywhere the inherited class is . [12.31:
. the type class is defined by its interface;
any type following that interface
is considered a member of that class .
. it's not about sharing code by extension;
it's organizing hierarchies of compatability .]

# type cluster combined with type classing:
. the subtypes of a type cluster
can be type classed; eg,
a dimensioned number could inherit from int;
and then to coordinate with the numeric supertype
it uses functionality from int.type
to deal with these messages:
{ what is your numeric subtype?
, your numeric value?
, replace your numeric value with this one
} .
. with just that interface,
any subclass of any numeric subtype
can be used in any numeric operation . [12.31:
. all self-modifying operations ( x`f)
can be translated as assignments (x`= f(x));
so then the inherited subtype
provides all the transform code .]

#type classing without clustering:
. without type clustering;
what does type classing do then?
are biop's supported? polymorphism?
. historical reasons for inheritance:
# polymorphism
# type compatability
# reuse of work .
. you want to extend a type's
structure and functionality,
not interfere with its code base,
and still be useful everywhere your ancestors are .

. in the popular oop model,
the inherited work is reused by
adding to an inherited type's
functionality and instance var'space
(creating a polymorphism in the type).
. there's type compatability because
the obj' can handle all the ancestor's
unary and self-modifying functions;
but, popular oop approaches differ on
how biop's are handled .

. the classic, math'al oop uses clusters, [12.31:
which can handle biop's because the supertype
has limited membership to its type class
and can thus know in advance
what combinations of subtypes to expect
among a biop's pair of arg's .
. in a system without clustering's
closed class of subtypes
then there is no particular type to handle
the coordination of mixed biop arg's .
(that mix can consist of any types in
one arg's ancestors, or their descendents).]

. if subtypes can redefine a biop,
then a biop's method might be arbitrated by:
# nearest common ancestor:
the arg' set's nearest common ancestor type;
# popular:
the first arg determines the method;
# translation:
. an inheritable type has a universal format
which inheritors convert to,
in order to use the root's biop method .]

# incremental composition:
. it can be simplifying to describe a type
in terms of how it differs from other types;
this case includes anything not considered to be
type clustering or subclassing .
. revisions such as removing inherited parts
can preclude type compatability;
in such cases, compatability could be declared
with the use of a conversion map .
. incremental composition provides
module operators for building in ways
familiar to lisp users:
code can read other code, modify it,
and then use it as a module definition .
. with incremental composition,
any inheritance behaviors should be possible;
but the built-in inheritance should be
simple, classic type clustering and classing
as described above .
. the directions of popular oop
are not helping either readability or reuse;
esp'y unrewarding is the ability to
inherit multiple implementations
that have overlapping interfaces .]

. generic types can implement frameworks:
a type is an interface with all code supplied;
a generic type
leaves some of its interface undefined
or optionally redefinable,
with the intent that parameter instantiations
are customizing the framework;
a typical gui framework would be impl'd as
a generic task type;
so that creating an obj' of that type
initiates a thread of execution
that captures all user input
and responds to these events by
calling functions supplied by the
framework's customizing init's .]

adda/oop/value types:
. the classic use of oop is type clustering
as is done for numerics:
it provides users of the numeric library
with an effortless, automated way
to use a variety of numeric subtypes
while also employing static typing,
and enjoying any enhanced readability or safety
that may be provided by that .
. coercions and range checks can all be
tucked under the hood,
without requiring compliance from clients .
. this automation is possible because
the designer of a type cluster's supertype
is using subtype tags to determine
each value's data format .

. the supertype module is also
the only place to coordinate
multiple param's having unmatched subtypes;
after one param' is coerced to match the other,
operations involving matched binary subtypes
are then relegated to subtype modules .

11.19: intro to value`type:
. static typing generally means
that a var's allowed values are confined to
one declared type,
and perhaps also constrained;
eg, limited to a range of values,
or a specific subtype .
. if that declared type is a type cluster,
it's values will include a type tag
for use by the supertype module,
to indicate which of its subtype modules
is responsible for that data format .

. type.tags are sometimes seen as a way to
replace Static typing with ducktyping
(where the tag is used at run-time
to check that the given value has a type
that is compatible with the requested operation).
. type clustering, in contrast to ducktyping,
is static typing with polymorphism
(statically bound to the cluster's supertype);
and there, the purpose of the type.tag
is merely to allow the supertype module
to support a variety of subtypes,
usually for the efficiency to be gained
from supporting a variety of data formats;
if huge complex numbers won't be used,
then a real.tag can indicate there is
no mem' allocated for the imaginary component;
if only int's within a certain range will be used,
then the format can be that of a native int,
which is considerably faster than non-native formats .

. the value's subtype (or value`type)
is contrasted with a var's subtype
to remind us that they need not be equal
as long as they are compatable;
a var' of type"real may contain
a value of type"integer;
because they are both subtypes of number,
and the integer values are a
subset of the real values
(independent of format).

. the obj's subtype puts a limit on
the value`types it can support;
while a var' of subtype"R16 (16bit float)
can coerce any ints to float,
it raises an exception if that float
can't fit in a 16-bit storage .

. another possibly interesting distinction
between var' types and value`types
is that value`types have no concept of
operating on self; [11.19:
a unary operation over a value`type
doesn't involve any addresses,
and there is nothing being modified .
. while popular oop has a var`address
modify itself with a msg,
eg, x`f;
classic oop would say that was an
assignment stmt plus a unary operation:
x`= x`type`f(x) -- shown here fully qualified
to indicate how modularity is preserved:
the function belongs to x's type .]

. adda can also enforce typing between
unrelated types like {pure number, Meters},
but the system depends on supertype designers
to correctly handle their own subtypes .

. in addition to the distinction between
{library, application} programmers,
there is also kernel mode:
the adda run-time manages all native types
so that any code that
could be responsible for system crashes
is all in one module .

10.23: news.adda/compositional modularity:
11.14: Bracha, Lindstrom 1992`Modularity meets Inheritance
We "unbundle" the roles of classes
by providing a suite of operators
independently controlling such effects as
combination, modification, encapsulation,
name resolution, and sharing,
all on the single notion of module.
All module operators are forms of inheritance.
Thus, inheritance not only is
not in conflict with modularity in our system,
but is its foundation.
This allows a previously unobtainable
spectrum of features
to be combined in a cohesive manner,
including multiple inheritance, mixins,
encapsulation and strong typing.
We demonstrate our approach in a language:
Jigsaw is modular in two senses:
# it manipulates modules,
# it is highly modular in its own conception,
permitting various module combinators to be
included, omitted, or newly constructed
in various realizations .
10.23: Banavar 1995`compositional modularity app framework:
. it provides not only decomposition and encapsulation
but also module recomposition .
. the model of compositional modularity is itself
realized as a generic, reusable software arch',
an oo-app framework" Etyma
that borrows meta module operators
from the module manipulation lang, Jigsaw
-- Bracha 1992`modularity meets inheritance .

. it efficiently builds completions;
ie, tools for compositionally modular system .
. it uses the unix toolbox approach:
each module does just one thing well,
but has sophisticated and reliable mechanisms
for massive recomposition .
. forms of composition:
#functional: returns are piped to param's;
#data-flow: data filters piped;
#conventional modules: lib api calls;
# compositional modularity:
. interfaces and module impl's
operated on to obtain new modules .

. oop inheritance is a form of recomposition;
it's a linguistic mechanism that supports
reuse via incremental programming;
ie, describing a system in terms of
how it differs from another system .
. compositional modularity evolves
traditional modules beyond oop .

. that compositional modularity
sounds interesting,
what's the author been up to recently?
reflective cap'based security lang's!

Bracha 2010`Modules as Objects in Newspeak:
. a module can exist as several instances;
they can be mutually recursive .
. Newspeak, a msg-based lang has no globals,
and all names are late-bound (obj' msg's).
. programming to an interface (msg's vs methods)
is central to modularity .

. it features cap'based security:
# obj's can hide internals
even from other instances of the same class;
# obj's have no access to globals
thus avoiding [ambient authority]
(being modified by external agents) .
# unlike E-lang, Newspeak supports reflection .

Newspeak handles foreign functions
by wrapping them in an alien obj,
rather than let safe code
call unsafe functions directly .
--. this is the equivalent of SOA:
whatever you foreigners want to do,
do it on your own box (thread, module)
and send me the neat results .

editor's uncluttered ascii mode

12.26: adde/ascii mode:
"( Many developers want ASCII-based editors,
in which case the syntactic clutter of
varying annotations
can rapidly become overwhelming. )
. adde makes it easier to use graphics
and other coded features,
by folding in code like html does,
but, for the sake of ascii tools,
it also needs to optionally provide
a file system that removes clutter
by putting the code into
files separate from the ascii .
. after modification by a foreign editor
the adde editor needs a way to know
how to merge the code with the text .
. for this it can use ascii bookmarks
which follow the head-body pattern:
their title indicates what they represent
and they have a pointer into the code file
showing where the body of code is
that implements that graphic .

. if adde finds a modified ascii file,
it checks for missing bookmarks
in order to delete the corresponding bodies .

. the code file is ascii too, of course,
but none of the words are about content
rather they give details of graphics .
. a foreign editor can see
the body of any given bookmark
by searching for the bookmark's pointer
within the code file .

. assuming that any given project folder
will have numerous text files
that may all need ascii-code separation,
one simple way to manage this separation
is to put all the code files
in a subfolder named code;
so that they can have
exactly the same name as the
ascii files they belong to;
so, if working on file: ./x,
--[the ./ means current folder ]--
then a search in ./code/x
will find the body of a bookmark .


optional ducktyping

adda/oop/optional ducktyping:
12.28: syntax:
. instead of optional typing,
what about optional ducktyping?
. the easy way to declare a local
is to have it's first use describe it's type;
ie, its declaration can double as its first use;
eg, v.t -- declares "(v) to be of type"(t);
and thereafter, the var's type ext is optional;
eg, v -- the var whose full name is v.t .
. in the case of ducktyping,
the first use has the null type;
eg, ( var. ) -- the dot at the end
assures the parser that you didn't
forget to specify the var's type;
rather, you want a ducktype compiled;
ie, the parser is to find the list of
operations that were applied to that var,
and declare that to be the var's interface;
eg, f(var.); g(var) .
-- that says var is a ducktype,
and its interface is: f(), g() .

12.28, 12.30: other:
. how are typed and ducktyped obj's interacting?
both {types, ducktypes} have type.tags;
but whereas a ducktyped object
carries the type.tag with its value,
the statically typed var stores its tag
in the local symbol table
of the subprogram where it resides;
ie, the symbol table storing a ducktyped var
will declare its type as null,
meaning to be delivered at run time .
. the type.tag is a pointer to the var's type mgt
which will have a dictionary of operations .
. during run time, the ducktype's type mgt is then
checked for having all the expected operations .

# a typed obj assigned to a ducktype:
needs to be wrapped in a type.tagged box,
ie, ducktyped obj = (value, type.tag);
and statically typed obj = (value) .

# a ducktyped obj assigned to a typed obj:
needs to be unboxed before assignment
(the type.tag is compared to the destination's expected type;
and, if compatable, the type.tag is stripped out,
and the remaining value assigned).
. the assigned ducktyped obj
then still virtually has the same type.tag,
only its statically in the symbol table
rather than dynamically beside its value .

review of the current stacking system:
. static types can help efficiency:
if a parameter is statically typed,
then the type's mgt can assist in
the typical amount of stack space
needed by the union of its variants
otherwise, the system can only plan on stacking
# a ptr to trailer (local heap); or,
# a ptr to readonly .

12.30: binary operations (biops):
. just like (statically) typed var's,
ducktyping can involve class clustering
where a biop's arg's can be ducktypes;
in these cases, the run-time is checking
that both arg's have a common supertype .
. an extension of that idea is where
any number of arg's can be accommodated:
# by checking all for a common supertype;
# by checking every arg's type for the presence of
a function with a compatible signature .

vector literals syntax

12.28: adda/dstr/vector literals:
. as with the declare's syntax
the opening angle brackets of the
vector literal formed with angle brackets
could be distinguished from less-than
by following it with a dot .
. ascii tokens are useful even with unicode
because, keyboard's can quickly dish up ascii .
. the parser converts ascii to unicode's:
less-than & dot -> opening vector bracket (U+27E8)
--. the closing pair is: U+27E9 .
related trivia:
Miscellaneous Mathematical Symbols:
U+27C0 ... U+27EF, U+2980 ... U+29FF .
'Miscellaneous Technical' 2300 ... 23FF:
(has a left-pointing angle bracket U+2329) .
--. ascii codes for {math relations, brackets}:
U+003C Less-than sign
U+003E Greater-than sign .
. unicodes that mac os x supports .


std input and gui interaction drivers

12.27: adda/arch/std`input:
. in my idealized expression of the mvc pattern,
the designers of apps should never have to
program the details of the user's gui;
they simply write to data structures,
and the user`agents have their favorite ways of
expressing structures graphically;
but what if the app designer
wants to contribute new ways of
graphical interaction ?
. such gui drivers shouldn't get direct access
to the mouse and keyboard (input events);
instead, like unix is designed,
drivers get gui events from std`input;
and, the user`agent is free to
feed the gui driver either the actual input events
or the user`agent's version of input events .
[12.29: for modularity:
. the gui driver's usefulness to some users
may depend on the user`agent's ability to
filter the user's input,
or simulating it with an algorithm;
eg, an adaptation for those with the shakes
might be to filter duplicate inputs .
adde plug-in's:
. the general way to develope the gui
is for adda, the compiler,
to be aware of plug-in's for adde, the editor;
a gui driver is associated with a typemark,
and then when adde is displaying
items of that type,
it lets the associated gui driver
decide how inputs translate into
modifying a value of that type .
. there can also be event-triggered gui drivers
(vs triggered by accessing a certain type)
eg, a selection lasso driver
would be triggered by a mouse-down drag,
and instead of stopping at mouse-up,
it would keep accumulating selection rectangles,
until, say, the enter key was pressed .]

declare block syntax

12.28: adda/cstr/declare:
. with a declare block represented by
this: .(BODY)
-- a dot-prefixed parenthetical --
it's immediately confused with a
type description literal;
instead, the syntax should be
a special case of function literal:
(.(x) BODY)
by just having a null parameter:
(. BODY);
function literals will eval
even when parameterized
-- if complete defaults are given
and the literal is not quoted --
and can thereby double as a declare block .

. the arg list can also be a
symbol returning type record:
(.myrec BODY);
[12.29: the point being that
anywhere a record def' literal can go,
a symbol for the same should be allowed;
but what about the syntax for functions?
-- that sets a precedent for
parenthetical literals not (yet) being
replaceable by a symbol;
but in that case,
the ().type pattern is there to
intuitively identify a function
-- f(x) = name & parenthetical literal .
. when expressing the function's arg type as a typemark,
readers need to be guided as to whether
a symbol is a {typemark, local param's name};
this can be done by using both
the paren'literal for "(this a function decl)
and the dot-prefix on the symbol
for "(this is a typemark):
eg, f(.typemark).returntype .
. the original (.(x) BODY) syntax
is modeled after ( var.type )
but puts the .(x) at the enclosure's opening
to show that it's typing the enclosure itself,
and not something the enclosure is qualifying;
it says:
this enclosure is a function of this arg, x,
eval'able when x is instantiated .

. the idea of typed enclosures representing sets
comes from:
# set-builder notation:
variously syntaxed as {x: body}, or {x|body}
either of which is generally ambiguous
given popular meanings for colon and div .
# types as sets of values:
to type a var without init'ing it
is to say it currently represents
a set of values .

. reasons why that syntax can't be
# parameters are intuitively expected
at the beginning, as is done in math:
{x: body}, or {x|body};
# (b).(x) is confusable with a type literal:
one expressing a function returning record .]

newspeak for Strongtalk

12.26: adda/arch/newspeak for strongtalk:

Bracha, a proponent of pluggable types,
was concerned that it weakened security
to rely on datatypes rather than
use oop`ducktyping everywhere .
. datatypes make several leaps of faith:
# the compiler has correctly analyzed
the program's compliance to type compatibility;
# the compiler's optimizations
still maintain this compliance;
# changes to the environment don't bedevil
assumptions required by this compliance .]

. Bracha, a proponent of Strongtalk
(smalltalk with pluggable types)
has moved on to Newspeak
but expects a pluggable typesystem
can be integrated later .
. Newspeak's most notable difference
seems to be capability-based security (cap's);
let's review what that does
compared to oop's ducktyping .

. oop's ducktyping calls turned
anything like f(x)
into x`type-mgt( operation:f, arg:x),
and x's type-mgt provides this service
for anyone who asks;
ie, if the current account can use x,
then any app running under that account
has permission to use x;
[12.29: whereas,
cap's are object-specific permissions:
an object accepts a call only if
the caller possesses a permission that
# specifies that object, and
# doesn't preclude the requested operation .
. a process starts out with no cap's
except those needed to remain functional:
it can accept arg's, return results,
and modify its own local mem allotment .
. other capabilities require
special permission provided by employers
(the user, admin, or os kernel).]

12.26: caller id:
. cap's are giving each app their own id,
so that cap'based calls would also involve
the caller id; [12.29:
it includes the concept of caller id;
like so:
cap's are awarded to particular id's,
and they are non-transferable;
so, then cap's are essentially a tuple:
(caller id, allowed object, allowed operations) .]

12.27: adda`plans:
. cap's can be controlled by
the run-time supervisor
instead of the current object's type-mgt .
. after the user has set limits on each app;
these become part of process records
(owned by supervision's task mgt),
and all attempts by a process
to communicate with others,
becomes a function of the capabilities:
eg, instead of asking to access the file system,
a process says things like,
"( let me modify the portion of filesystem
pointed at by my process record's writableFiles cap' .)
"( let me read all files within
my process record's readableFiles cap' ).


Gilad Bracha's pluggable types

adda/gilad`pluggable types
12.26: varieties of encapsulation?
Typical language semantics depend on the type system
(e.g., casts, overloading, accessibility).
By eliminating this dependency,
we can make our languages more modular.

Class-based encapsulation
(relies critically on complex and fragile
typecheckers and verifiers)
-- very popular, but inherently less secure than
object-based encapsulation
(enforced only by context-free grammar).
Typecheckers are tricky and often buggy;
whereas, parsers are well understood.
--. optional typing simplifies language design,
to the benefit of the system as a whole.

12.27: understanding the concept:
. how can types be optional in smalltalk
when in fact smalltalk has an inheritance hierarchy?
aren't oop classes acting as types?
. oop typing is by definition "(optional);
because, it depends only dynamic typechecking .
. manditory typing (vs optional) is when
the code won't compile until after
the static typechecking system has verified
(by analyzing declared types and compatible assignments)
that any future object can handle
any of the messages they may be sent;
smaltalk's oop never assumes future knowledge;
rather, every function call consists of
sending the object the name of the message,
and then that object can verify for itself
-- before accepting the current call --
whether it can handle a message of that name .

. the main idea of pluggable types
is that while smalltalk oop's
dynamic typechecking is a great idea,
static analysis has additional value
-- both can coexist together .
. a lang's type declarations are optional
when the lang's compiler can generate code
regardless of whether
the type declarations exist .
. type declarations are pluggable when
when developer tools support multiple
static type declaration analyzers;
a test run consists of
first sending the code to the current analyzers;
if there are no warnings,
then the code is sent to the compiler .
. given some warnings, the developer can still
opt to compile the code anyway,
which will run until at least until caught by
any run-in's with dynamic typechecking .

12.11 ... 12.12: news.adda/gilad`pluggable types:
. I found pluggable types mentioned in
a comment on a forum where Mark S. Miller
explained why capabilities rule and ACLs drool:

"(. Gilad, in his Pluggable Types manifesto,
talks about serialization as part of his
justification for why the vm's execution
shouldn't depend on types . )
-- z-bo
"(... the software systems equivalent of
Padlipsky's The Elements of Networking Style...
demonstrating why, in the software industry,
everything we do today is moronic and monolithic.)

ppt for bracha`pluggable-types.pdf:
. static type is characteristically mandatory;
types should instead be optional;
a paradox of using type systems for
reliability and security
is that while they can
mechanically prove properties,
they are making things complex and brittle;
eg, type systems for vm and lang collide .

. persistence works best with structural typing;
whereas, nominal typing (declared by a type name )
forces the serialization
(a subsystem for persistent filing)
to separate objects from their behavior;
it can't tolerate a type's name being
associated with more than one impl' .
[12.27: well,
that's why there are class clusters,
where the type mgt declares a std format
for all member types to file their state as .]

12.12 ... 12.13: gilad's complete paper:
Gilad Is Right:
. the talk notes need backing by this paper:
(found here)
class-based encapsulation
vs object-based encapsulation ? ...
. Class based encapsulation.
class C
{ private secret.int
; public expose( c.C).int { return secret;}
} -- there is no way to know
when access to encapsulated members is allowed
without a (prohibitively costly) dynamic check.
Instead, use object-based encapsulation,
as in Smalltalk or Self .
. keep in mind he's talking about
merging dynamic with static typing;
object-based encapsulation? how about:
"Object-Oriented Encapsulation for Dynamically Typed Languages":
"( Encapsulation in object-oriented languages
has traditionally been based on static type systems.
As a consequence, dynamically-typed languages have
only limited support for encapsulation;
this paper is bringing encapsulation features
to dynamically typed languages.) ]

[12.27: the point of the example of
class-based encapsulation
was showing how it allowed for declaring
-- in the interface (vs class body) --
the body of an accessor
that accessed an instance var;
whereas proper interface-body separation
doesn't allow any assumptions about
what an interface entry does with privates .]

. using the assumptions of smalltalk oop,
a method can be accessed without knowing
the obj's type or class;
ie, if it doesn't support that method
then it simply returns nil,
or otherwise raise a not-supported.exception .

. overloading functions implicitly requires
nominal typing of function parameters;
not good ...
bewildered? a concrete example is strongtalk!
(originally at www.cs.ucsb.edu/projects/strongtalk)

12.26: complete text (found on his site):
Pluggable Type Systems Gilad Bracha October 17, 2004

12.26: Strongtalk`history:
Dave Griswold was frustrated with the fact that
there were still a lot of obstacles to using Smalltalk
in most kinds of production applications.
. it was still way too slow, [but simple]
had poor support for native user interfaces
(but portable)
and lacked a [static] type system,
which although it makes the language flexible,
also means large-scale software systems
are a lot harder to understand .
. by 1996 the system was transformed
by Urs Hölzle's speedy compilation technology,
and Gilad Bracha's type system for
but then the Java phenomenon happened;
years later, Sun finally open-sourced Strongtalk .

New repository location for Strongtalk 4 Oct 2010
new repository location on github
You will also find the first steps on a
Newspeak port on branch nsreboot.

strongtalk overview:
. the type system is not concerned with
improving execution performance,
since it is based on interface types.
Optimization requires concrete
implementation type information.

key characteristics of the Strongtalk type system are :
* allows natural Smalltalk idioms to be typechecked:
1. Separates the subtype and subclass lattices.
2. Includes parameterized types and classes.
3. Supports parametrically polymorphic messages,
with a flexible mechanism for
automatically inferring actual type parameters.
4. Supports both subtyping and type matching.
6. Provides facilities for dynamic typing.

5. Preserves the subtype relations between classes
defined by the Smalltalk metaclass hierarchy
and relates them to the types of their instances.
A protocol is a collection of message selectors
and their associated signatures;
Every class C automatically induces a protocol,
The type hierarchy is defined using protocols.

* The system provides the same kind of
reflective access to type information
as Smalltalk does to other language constructs.
Note that if a program does access
type information reflectively,
then by definition its behavior is dependent on
the type annotations in it.

Strongtalk supports two relations on types:
# Subtyping (substitutability):
an element of a subtype can be safely used
wherever an element of a supertype is expected.
# Matching (common pattern of self reference):
. Every protocol definition specifies its supertypes.
Likewise, a class definition can specify
the supertypes of its protocol.
By default, a protocol is declared to be
a subtype of its superprotocol.


managing capabilities without encryption

12.7: adda/cstr/managing capabilities without encryption:
. in a read of capability-based security
I wondered if there was some way to
have capability enforcement
without having to encrypt all the shared pointers .
. related ideas include:
# Singularity's faster task switching
done by using ref's to shared mem'
instead of passing copies between modules;
# how to use pointers to shared resources
so that even though 2 concurrent sharers
were both active at different processors,
only one active sharer at a time
would have a useful link to the shared resource .
sketch of a possible design:
. a process can never reach out directly,
but is always accessing things via
pointers located in their header,
and only the supervisor can modify this header;
eg, the task scheduler .
. it's not enough to have possession of a pointer,
you've got to have a supervisor
copy it to your header;
so, it's like encryption,
in that it requires an authorization .
layers for when bugs happen:
. encrypted cap'pointers are being
another level of security; [12.25:
. cap'based is supposed to include
the soa idea:
. bugs are going to get into the system,
but in a software system that
connected it's modules
the same way https connects computers,
then it wouldn't matter bugs had invaded;
because each of the components is
being separately guarded by modularity
(not allowing direct access to state)
and is working only with ID'd clients
(not servicing anonymous agents).
. the idea of unencrypted header pointers
is assuming that
the system's runtime can be secured
which is not likely
on today's monolithic OS's .]


icons of the alphabet

12.23: adds/icons of the alphabet:
. abc's look like the very basic mechanisms
whose names begin with such letters:
Angle(A is icon of angle arc between hinge plates)
Bisect(graphical counting or dividing),
Circumfrence, Diameter,
Extend (greek E means summation)
Front (arrow points at front surface of a drafting view
-- vs the top surface),
Gyration (revolving starts from right angle),
Hinge (H can be plates hinged),
Iatric(healed, parts assembled
-- I is a clocking of H)
Join(J has a hook for joining)
Kaleidoscope (K shows both V and V's mirror image)
Ligature (bonding of multiple indep'dimensions
-- symbolized by L, a right angle).
Multiply (M is a clocking of E, summation)
Not(N is the same shape as set`not: ~)
Oscillation (O is loop like cycles, oscillations),
Post-Oscillation or Product
(P is icon of dropping out of a loop)
Quality (what's under Oscillation? its basis or control)
Radical (Oscillation's side affects)
Specialization (S looks like yin-yang formations
-- specializing in complementary differences)
Top (arrow points at top surface of a drafting view)
Union (U looks like a collecting cup)
Vacillation (V is side view of wave, VVVV)
Wall (W is a counter-clocking of E, summation
-- stop additions)
Xiphoid (Greek xiphos: sword)
Yes (what's under Vacillation?
-- basis or control of V, energy)
Zero (Z is a clocking of N, not(this): not anything)



12.16: news.adds/culturomics:

Quantitative Analysis of Culture Using Millions of Digitized Books
"( We constructed a corpus of digitized texts
containing [5 million books]
about 4% of all books ever printed.

Analysis of this corpus enables us to investigate
cultural trends quantitatively.
We survey the vast terrain of "culturomics",
focusing on linguistic and cultural phenomena
that were reflected in the English language
between 1800 and 2000.
We show how this approach can provide insights about
fields as diverse as lexicography,
the evolution of grammar, collective memory,
the adoption of technology, the pursuit of
fame, censorship, and historical epidemiology.)
Google Tool Explores 'Genome' Of English Words

. To coincide with the publication of the Science paper,
Google's ngrams web app shows how often
a word or phrase has appeared over time
in its scanned literature .
Dr Jean-Baptiste Michel a psychologist in Harvard's
Program for Evolutionary Dynamics,
and Dr Erez Lieberman Aiden
have developed the search tool .

. 8,500 new words enter the English language every year
and the lexicon grew by 70% between 1950 and 2000.
But 52% these words do not appear in dictionaries.
– the majority of words used in English books .



3.24: adda/multi-interfaces:
. just as oop classes have different interfaces for
clients vs subclassers,
adda needs a sublanguage for describing
multiple interfaces
and the various actors that can access them .
. dimensions for having separate faces include:
roles, security levels, priorities,
business arrangements (eg, demo.ware vs full-service),
and partner name (where the degree of allowed reuse
depends on which partner is doing the reusing ).


pico puts some clothes on lisp!

12.13: lang"pico:

. what kind of academic site would drop their link
to an important paper like Gilad Bracha's
pluggable types! ? welcome anyway,
to Brussel's Vrije univ's pico project,
the marriage of Scheme and normal infix notation
for a lispy pascal !

Pico is the smallest but expressive language
for teaching computer concepts to
non-computer students (eg, Physics and Chemistry).
. it adapts Scheme's syntax (significantly)
and semantics (subtly):
* the semantics had to be simple
even if some Scheme features became inaccessible.
* the syntax had to be like that in math;
* ease-of-use, portability, interactivity...
must have priority over performance;
Pico features garbage-collected tables (i.e. arrays),
higher order functions, objects,
meta programming and reflection.
* Pico as a language had to coincide with
Pico as a tutoring system;
the boundaries between programming and learning
had to be totally removed.

Pico is no longer used as a tutoring language
but this is a consequence of mere politics;
[eg, mit moved from Scheme to Python
because Python too was a good teaching lang'
that was also useful (eg, for working with
the new robotics lib' mit adopted).]

Today, Pico is still used as a means to teach
principles of language design,
interpreters and virtual machines
in a sophomore course:
Theo D'Hondt's hll concepts:
. all software used in this course are built in Pico.
Even the virtual machine itself is built in Pico
(it is a so-called meta-circular implementation
using a previously created ANSI C Pico machine).

Theo D'Hondt's computational geometry course:
. it uses c and version of pico
( a graphical extension
with syntax modified to enhance readability).

Theo D'Hondt's Growing a Lang from the inside out:
Programming Language Engineering
is the assembly and mastery of
constructing and applying
programming language processors.
. we need to review research like continuations,
and critique the current attempts at concurrency .
. this series of lectures discusses the need for
language processor design to be extensible,
similar to Guy Steele's 1998 OOPSLA phrase
“Growing a Language”
refering to the need for an expressive core
that is easily extended .
We need to bridge the gap between
the abstract concerns addressed by the language
and the features offered by the hardware platform
-- keeping in mind software reuse .

12.14: beyond pico:
AmbientTalk is influenced by E.lang and pico;
it's intro'd here along with google's Go.lang:
Another evolving area of computing
concerns programs running on mobile devices
linked in "ad hoc" wireless networks.
AmbientTalk, an experimental language presented by
Tom Van Cutsem from Vrije Universiteit Brussel in Belgium,
explores a new paradigm called
"ambient-oriented programming,"
which departs from traditional distributed computing
in two main ways.
First, it does not rely on central infrastructure.
Second, it's smart enough to buffer messages
so that when the connection drops,
they're not lost, and when the connection is restored,
it sends the messages through as if nothing happened."

12.13: adda/double colon operator in pico:
. pico'declarations (name::value)
introduce immutable symbols (i.e. constants)
whereas pico'definitions
introduce assignable names [variables].
# Definition
eg, x:4, add(x,y):x+y, t[5]:10
a variable is defined, a function is created,
or a table is allocated and initialized.
# declaration
[defines the same things, but immutably];
eg, Pi::3.14, t[3]::void and f(x)::x.