oop (obj'oriented programming)

8.16: adda/oop/avoiding unnecessary polymorphism:

. when is polymorphism required?

[12.19:

. type polymorphism is that aspect of oop

which is most essential to simplifying a system .

. it comes at the cost of data using additional memory

in order to specify a type.tag,

which can be used at run time,

to determine which routines can actually handle

the type an obj' has at the time of the call .

]

. when can adda replace an arithmetic expressions

directly with c native types ?

it has to know at compile time what the input type is .

. the important feature of the translation system

is that it lets you specify type info if you want to;

and, program efficiently as in c;

but then, it also makes sure

that you follow all the rules

that are needed to safely use c's numeric types .

. initial versions of adda may want to simplify things a bit

by just converting all code to the oop version of numerics .

8.28: adda/oop/private vs public:

. is there some slicker way than explicit tags

to indicate whether a package symbol is {public, private} ?

. start with the idea of 1st-class functions:

sub's are declared like local var's .

. publics are declared in the body of a datatype or type.class .

. locals of types are found in the bodies of their operations,

or in their instances (instance var's)

or in the locals of type'mgt (class var's),

ie the body of the type's def' .

. how is the type'mgt process defined?

[12.19:

t.type`= [/]value; where in this case,

[/]value is interface .

then t`body`= value; where the value of the body

is a list of def's for symbols found in the interface .

]

. just as every type needs to define or inherit

the instance's {ini, fini} handlers, (12.19:

for the instance var's)

it also needs to define a sys`{ini, fini} (12.19:

for the class var's in the body of the type's def') .

[8.29:

. the var"(sys) is a process rather than a procedure,

so it is retaining the activation created by sys`ini

until the run-time system calls sys`fini .

. this activation record contains locals

that can be shared among all type`instances`operations

by referring to sys`/somelocal/ .

]

8.29: revisited:

. rather than have the public symbol"(sys)

being the activation record for the type`mgt,

the design should be more like that of ada's package .

. think about 1st-class functions,

and how a var' of type"(function) has as part of its

type description -- indep' of its value --

the type's of its param's and expected externals;

eg, f(x.t).rtype .

. this type description can be thought of

as similar to the head of an ada`package .

. likewise, the function's value

-- it's algorithm and activation.record`declaration --

is similar to the body of an ada`package .

. in both cases, you implement body by refering to just that:

eg, f`body`= (.(x) code for expressing f(x) ) .

. ada's way is for a package to be initialized once

upon activation of any client;

this apparently works like multiple readers opening a file:

. reader activation does an open,

then the system checks for it being open,

and does so only if needed .

. in the analogy with functions,

notice that the parameter symbols are expected to

match those in the body of the function

(the assigned algorithm) .

. likewise, symbols in the head of a type's def'

are visible in the body of the type's def'

-- and are expected to be defined in the type`body

just as parameters with defaults are defined in the function`body .

[12.19:

. the type's body is like an extension of the type's face;

except the body's symbol's are not visible to the face .

. the body and the face together are like a {record, struct}

whose fields can include functions;

again however,

while it's possible to use record notation to

qualify a type's functions: eg, number`+(...);

it is not possible to access record fields

without qualifying them with record notation .

. when defining the bodies of face's functions separately from the type`face,

it's assumed that bodies have access to

locals within the body of the type'mgt .

. this will seem natural if the function's bodies are

defined within the type'mgt's body,

as they will obviously be within the same scope;

but the same is also true if a function's body is defined separate

from both the type`face and type`body .

. this is simply being consistent with

the way things are for nested subprograms .

. when things are separate,

all expected externals must be part of the param'declaration;

otherwise, it's assumed that the separation is perfectly modular .

]

8.29: sci.adda/oop/inheritance:

. is there an elegant, intuitive design for inheritance?

. there are several dimensions:

first:

. there are several use-cases for inheritance:

reuse of implementations,

reuse of interfaces as in type-clustering,

and reuse of interface as in assignment compatability,

or familial class affiliation .

2nd:

. the entire lifetime of components must be considered:

. how can subclasses update themselves in a way

that is not going to break things .

. when type compatability is the goal,

then, as in ada, there is a typedef for that:

t.type`= is and(t1, t2, ...) .

. for those that are trying to simplify design

by describing one type in terms of another,

but don't want compatability,

t.type`= ( include t1 - --[minus this list of symbols]

, include t2`body -

, ... )

--. this example shows inclusion options:

including t2`body implies inclusion of the head,

whereas, inclusion without specifying the body

refers to just the head .

. another option is whether to do include's dynamically;

or to mean that the current definition should always be used,

regardless of whether that definition changes .

. in the static version, inheritors would be notified

that previous building blocks have changed .

. dynamic versions would work in a modular way,

where a type or any other module is a plug-in,

which can be replaced with another plug-in (having a different body) .

that may have an extended interface .

. now, since clients could have also have extended that interface,

accepting dynamic inheritances must mean

that any changes to the interface are seen only by future clients .

. previous clients would be asking for links only to

those symbols in the interface that they did inherit .

8.29: adda/oop/derived vs primitive:

. obj'c's definition of "(derived function)'s

are those methods defined in terms of the primitive methods;

implying that when you inherit from an abstract class,

the derived functions are already implemented for you .

. how should adda syntax indicate what are primitives ?

. ada's primitives are the ones in the head of a package .

. in hierarchical pkg's, the child packages are not primitives .

. eg, type number has only primitives,

then number/lib has derived fun's .

9.13: adda/oop/efficiency through compiler work:

. how is adda giving type.class's privacy

while also allowing selective typing

without making users talk about un|boxing?

. just let the users use type.class|cluster's,

and then if they use an obj' in a way that

conforms to the protocols of a native type,

then let the compiler make the replacement .

9.13: adda/oop/cluster and type tags:

. the type.tag can be a full int,

as it can store not only type but also size of current obj

(eg, numbers are often an array of ints

whose size is depending on the number of digits in the number),

. a negative tag could indicate special situ's,

like when there is no data besides the tag,

and the tag itself indicates a named constant, (eg, e, pi, ...) .

. the neg'tag could also help with efficiency in other situ's:

. tall types add only a few values to the type.tag:

(ptr, func, immed),

so then a neg'tag could be indicate to the decoder

that this has got a tall field to pull out,

and then the remainder of the int is the type.tag .

. dynamic typing allows an obj' to be any type.cluster

(ie, string, number, ... );

so then neg'tagging could indicate the type.tag includes

both the type.cluster and the datatype .

review of clusters:

. number is a type.cluster because it clusters

the type.classes" {R, N, Z, C, Q}

. the type.class of Z contains the datatypes:

(int8, int16,int32,int64, int-multibyte) .

. once the type.cluster.tag is known,

the datatype.tag`code can be understood,

(because it's registered with a particular type.cluster) .

. then calling datatype`type.class

will tell whether it's a {R, N, Z, C, Q} .

. user`defined type.classes can specify range limits,

and then the compiler and/or type-mgt can translate this into

what datatypes to use for it .

10.14: adda/oop/inheritance forking:

. one benefit of inheriting

is it allows a base class's code fixes

to be auto'ly applied to code of inheritors .

. a problem is when the super class wants to

change its impl' in a way that breaks the code of subclasses .

so,

need idea of a subclasser's interface

similar to idea of clint interface

. if super changes subclasser's face

then these changes cause a fork in the inheritance

so that past inheritors can keep the code they have,

while new inheritors can build against the new face .

[12.23:

. this idea depends on a robust contract-expressing system .

]

adda/oop/needs auto'unit testing:

. any time a superclass updates,

unit testing is run by adda on the subclasses

for checking that the change doesn't break code

since even if face the same,

critical behaviousrs could have changed .

. a common misbehavior is when a server

switches employees who don't get it[the contract] .

10.14: adda/defining auto'conversions by converter visibility:

. when specifying subtypes

there are 2 options when constaints are broken:

* warn user (raise exception)

* auto'ly convert:

eg, when inches are assigned to mm

then it auto'ly does the inch2mm.conversion;

eg, when real.type is assigned to int, then do the rounding .

. conversions make sense whenever available,

whereas, if a subtype restricts the value's range,

then when values are out of bounds, an alert is required .

10.16:

todo.adda/modular type.def:

. t.type`= < literals, uniops, biops >

t`literals`= {...}

[10.18: this may be too unlike vectors ...]

. how is inheriting like something else

so that they can share syntax?

adda/oop/obj'composition:

. obj'composition (ooc) involves building trees a lot

since all is ptr-based .

. this reminds me that in addition to local heaps

potentially large obj's may want their own heap .

. also,

recent plans saw a need to keep globals showing current heaps

this may need to include current obj .

10.16:

adda/oop/selectors and literals as symbol.pointers:

. by the recent definition of const,

the type can be inferred from the value

but this is only when the value is present at the time of declare .

eg, var.!`= init,

and it assumes every literal can be identified as

belonging to a certain type.class,

so then the var`type is

whatever the init's type is .

. the polymorphism can be seen in the example of

the file.interface

which includes responding to the open.function .

. consider the open.symbol to be a global,

so then the open.message is just a symbol pointer

rather than a method (code) pointer .

. likewise, all of the literals are global symbols,

and a type whose literals are symbols

has bit.values that are actually symbol pointers .

. for the efficient enum typing,

the type is actually describing

a function: symbol-> bit.vector .

10.22:

adda/oop/category:

. obj'c relates the word category to classifications

. I recall from philosophy that category had a particular meaning:

eg,

the category of quantity includes:

{ nullity, unity, infinity, 1/infinity (infinitesimal),

cardinal, ordinal, complex, ... }

--ref:

. Aristotle had claimed that the following ten predicates or categories

could be asserted of anything in general:

substance, quantity, quality, relation, action, affection (passivity),

place, time (date), position, and state.

"Category`root is Greek"kategoria:

"that which can be predicated about something

(publicly declared and asserted)"

A category is an attribute, property, quality, or characteristic

that can be predicated of a thing. "

... I remark concerning the categories ...

that their logical employment consists in their use as

predicates of objects."

Kant called them "ontological predicates."

10.22:

adda/oop/type vs subtype:

summary:

. from learning about obj'c oop,

I'm becoming aware of missing ideas for

how I would say all things oop in adda's lang' .

sci:

instead of type.type's that can be either new or subtypes,

let type.type imply that a new is being declared

whereas, a subtype.type implies compatability .

. mailbox is a {species, type} of container (a subtype of container) .

. num.type; int.subtype`= num .

. if int is a num, then num`= int;

if num`frac =0, then int`= num .

. num =z, r, q, n,

how to express subtypes?

ir = infinite repetitions: (e, pi, ...)

z = n u -n

q = z/n,

r = z+q u ir

c = r + r i => z

q is about having divisions be treated like const irrational symbols

since they are not exactly reresented in finite ways,

so save the dividing operations when float.types are needed .

. irrational types may be represented by functions that

give the const to a given (arbitrarily large) precision .

(and like the division, be expressed only when float.types are needed).

. any obj' expecting num's face (available operations)

can work with ints too

but compatability depends on direction of assignment;

eg, a parameter's type will differ

depending on whether it's assigned a value or an address for out.mode:

an obj's subtype is a constraint confining it to accepting only a certain subtype .

[10.28

. the value must be a subtype of the address it's assigned to;

the address must be a supertype of value being assigned to it .

{super,sub}.type is an ambiguous terminology;

in obj'c and much of oop literature,

the subtype is able to respond to

many more functions than objects from it's supertype .

. that's because the subtype is constraining the inherited set of values

to those that make sense being applied to the additional functions .

the parameter may potentially need 2 types:

one for what subtype it expects from the caller,

and another subtype telling the compiler

what it expects the range to be within

while being operated on by self .

. there are several typing mechanisms to consider

and there should be integration wherever possible .

. dimensioning is a sort of datatyping

where numeric values have factors indicating

what substance they are amounts of .

. ada has something like interfaces,

but is related to dimensions in that

instead of letting numeric type mix with any other,

they have to agree in dimension also;

that means that they follow an interface but apply a constraint .

. in addition to dimension is coordinate systems

involving umbrella types of sorts

since there should be a way to convert between any coordinate systems

that are being used to measure the same dimension:

eg, length can be in inches, feet, the sum of both, or meters .

. oop is all about subtype polymorphism:

assignment compatability between various types

for various reasons .

. the sort of oop that type"number is an example of

is called nominal coercive subtyping

where various types (complex, real, integer, rational, modular)

are nominated to be different implementations of some umbrella type (number)

whose job it is to handle conversions and relegation;

eg, (int / complex) is a mix of subtypes

that needs to have one type converted

so they will both be the same subtype

to which the operation can be relegated to:

(complex/complex) -> complex .

. all other forms of oop are called inclusive rather than coercive

because instead of being able to mix subtypes within binary operations,

the interface is confined to unary or parameterless operations .

. the sort of oop exemplified by obj'c inheritance

is called nominal inclusive subtyping

because subtypes are nominated by declaring who their supertype is .

. the sort of oop exemplified by obj'c protocols

is called structural inclusive subtyping

because instead of nominating a type to be compatible with

its abstractly refering to any type that uses the same structure

(complies to the same interface or protocol,

ie, responds to the same set of messages)

. it's inclusive:

they are sharing the same interfaces

(the structure of assignment compatability) .

. the original extent of oop in Python was parametric polymorphism,

where instead of a parameter declaring itself to be of a given type,

it can be compatible with any type that can respond to the needed messages .

. this would be structural generics

in contrast to the nominal generics provided by Ada

where a parameter's type can itself be a parameter;

ie, the caller has to supply the name of the type

to which the other arguments belong .

(Ada additionally requires this be done in 2 steps:

intstantiate the generic,

and then use result with your chosen type) .

]-10.28

10.28: bk.engl/subtype:

http://en.wikipedia.org/wiki/Subtype_polymorphism

If S is a subtype of T,

any term of type S can be safely used in a context where

a term of type T is expected.

. this is called subtype polymorphism

vs, parametric polymorphism, the term for generics .

(nominal subtyping)

The class-based object-oriented subtyping described above is nominal;

(structural subtyping)

a structural subtyping rule for an object-oriented language might say

that if objects of type A can handle

all of the messages that objects of type B can handle

(that is, if they define all the same methods),

then A is a subtype of B regardless of whether

either inherits from the other.

Implementations of programming languages with subtyping

fall into two general classes:

(inclusive implementations)

in which the representation of any value of type A

also represents the same value at type B if A<:B,

The subtyping induced by subclassing in oop is usually inclusive;

(coercive implementations)

in which a value of type A can be automatically converted into

one of type B.

. subtyping relations that relate integers and floating-point numbers,

which are represented differently,

are usually coercive.

10.23:

adda/oop/mixing tagged vs constrained:

. complication

when some num's are not boxed (type-tagged),

there needs to be assignment to unboxed with compiler indicating type

eg, int in {int, mod}{8,32, 64, 128} .

. also need to separate adt from polymorph's,

eg, if Q is needed without translation to other subtypes of num

then no type.tag is needed while compiler

statically converts literals;

eg, x.Q`= 4(= 4/1) -> [Q be fraction](x, 4,1),

10.23:

sci.adda/oop/supertype:

. num.supertype is < subtypes: Q, Z, N, C, R ...>

todo:

. impl' num.supertype to get idea of how to make syntax for

supertypes generally .

. notice the behavior of supertype

can be drawn from def's of its subtypes:

instead of going on tag,

see if any has value that can be reduced to a simpler subtype:

Q`frac = 0 ?

tag an N = 0.1, ... inf,

... ((ideas about how to give special operators for particular subtypes)) ...

C= real * complex.sign

C= * complex.sign

R = C sign`im = 0

Q = R- ir's

space in {continuum, discrete}{value, sign}

C= continuum.val * continuum.sign

R = continuum.val * discrete.sign

N = discrete.val

M = modular discrete.val ( max+1 = 0, 0-1 = max )

[10.24:

. modular is usually described as a

partitioning by equivalence classes:

. for N modulo 8, the classes are {0..7}, {8...15}, ...

0 mod 8 =

8 mod 8 ...

and this system should also make sense for reals

(that would be sub.second clock arithmetic) .

10.29:

. it would work for any reals, not just floats,

it's clock arithmetic where numbers are equal if they are

the same angle on the clock dial .

]

10.24:

adda/oop/supertypes declaring subtype:

num.supertype is

< ;;;

sub: R, Q, N, Z, C

; uni: -, /, log#{2,10,e}, sign, value, `real, `im

; bi: -, /, *^, |

; multi: *, +

>

. the idea at the moment about oop architecture

is that supertypes (type clusters)

are the main type and you don't need to

worry about later adding a type (subclassing)

because the theory of the type involves

being aware of all the subtypes in advance

because this is required for knowing how to handle

cases of mixed-subtype binary operations;

that is,

for this kind of type,

you couldn't add a subtype without having to

recode the mother type anyway .

. then for the other features of oop,

there would abstract interfaces (protocols)

and an implementation would have the option of

importing another implementation (cloning for subtyping) .

. this is very simple while also powerful .

10.25:

adda/oop/sizing.tags:

[11.2: intro:

subtype.tags -- in contrast to type.tags

which identify who mgt is --

are used internally by type'mgt to distinguish between

impl'variants;

eg, the same 4 bytes of a number may be used as

either a single integer,

or as a pair of ints that make up a fraction;

so, the subtype.tag would tell number`mgt

whether this obj was an large integer or a fraction;

whereas,

the type.tag would identify the type.class;

eg, number vs character .

. type.tags are needed when a parameter has

no particular type;

rather, it's declared only as being

any type supporting a particular interface .

. oop is known to be memory-intensive

because it's based on adt's

where instead of an obj's state being determined by

a particular set of functions constituting the obj's type,

it can be defined by any number of types

so that the given state can be identified only by

knowing -- by type.tag --

what type has been designing its state .

. in its most free form, adt` obj's can be of any size,

so then it becomes common to implement an adt` obj

as a pointer into a varying-sized string of memory .

this pointer and tag.type

can easily add 2 bytes to every obj' . ]

. one way to reduce this use of memory

is by having types declare sizing variants

each of which consists of a starting size

and whether it wants the option to be growable;

eg, a typical number will fit in 4 bytes,

but depending on the number's subtype or value,

it could need many more bytes,

so then this need to grow

would be accommodated by

using some or all of the original 4 bytes

as a pointer into some heap (typically the heap would be

the trailer.space of the enclosing act'rec or container) .

[11.2

. if the system manages all bit & byte-level addressing,

then a type can resize without being aware of the details

of how the growing took place;

in fact,

perhaps this is best done by the system,

where the system analyzes what sizes the type uses per value ranges,

and then declares this sizing for a type;

however,

wondering if type developers might be able to

design more efficiently

if they knew the details of this scheme

and were partners in it .

]

. to support this sort of variant structure,

the system would need to add a sizing.tag

that indicated whether an obj had been extended into trailer.space .

. the sizing.tag could also indicate a variety of base sizes,

or else the base size could depend entirely on the subtype.tag

[11.2:

. due to there being allignment requirements on some platforms

(eg, a 4-byte integer works fastest on a 4-byte boundary)

and considering the varying size of tags,

the best way to store tags for items in structures

(arrays, records, act'rec's, etc)

is to dope-vector them out to the struct's trailer.space .

. this way the system is free to dynamically change the tag impl'

to take advantage of circumstances such as

finding that all obj's are the same type,

so then in that case,

all the type.tags could be replaced by the variant:

[this tag applies to all items] .

. likewise for sizing.tags .

. with this ability to dynamically restructure the tagging info,

the system's efficiency can come in increments .

. the array structure can change indep'ly of its components:

. the array's header contains the type for the whole array,

and if it depends on the index,

then the header will indicate it's a dope vector into the trailer,

pointing at a bit.field array that grows in size

to match that of the data.branch of the array .

. if all components need type-tags,

then the size of the type.tag depends on

the degree of variation:

eg, if system determines this array will contain only

2 types,

then the remembering the choice between these 2 types

can be mapped to a single bit .

]

adda/oop/static vs dynamic polymorphism:

. if oop design is looking complicated,

keep in mind the priorities:

type.clustering (subtyping, like numbers do)

and interfaces (protocols) .

. clusters provide static vs dynamic polymorphism;

it's the dynamic subclassing that is very problematic .

adda/oop/type.cluster"{string, tree}:

. suppose type"string lets string's variants include

either ascii, unicode, wordcode, or ptr to str;

in that case:

string insertion can be speeded up by tree operations .

. new subtypes can be joining the string.type

by following the interface

which includes being able to report self`size

and whether all char's are fixed size (vs varying like unicode) .

. array's (a generalization of string)

could work like this too;

or instead,

refer to the above style of str's as being char.tree.types

rather than char.string.types .

. tree structuring really helps when instance`sizes are sure to

vary within a subclass.

10.28:

adda/oop/obj`size but no simple type`size:

. sizeof with polymorph's?

it can be complicated getting the size,

there is also an arrayable version

that is with a fixed-sized head, and a vari-sized trailer .

[11.3:

. if it's any use, there is always current size per obj',

and per container,

but not the type`size that c users are accustomed to;

then again, they won't need the size to find

the needed mem'size to alloc .

] .

10.29:

todo.adda/oop/need to back up terminology: [done]

. diff'ing supertype vs superclass:

( supertype is coercion mgt;

so, there's just one root type

vs,

superclass can inherit from a non-root class

. also diff subclass vs [11.6: subframing:]

reuse of body along with face

adda/oop/structural compatability:

. to support structural compatability

as expected intuitively,

(eg if 2 arrays have the same component type,

they should be able to share slices),

the previous syntax for subtype may [need to] assume

compatables must be nominal var

[??]

can be any type until typed by dimension .

...

. if no type is given for a value param'

the initial set determines its type structurally .

. the values can be

symbols (words), numbers, char strings:

all value types

have literals within the union of these 3 sets .

mis.adda/oop/type`literals/frame.tag as impl'inheritance:

. in a literal that is defining a type by vector

when there is a frame.tag

it is listing who it inherits a body from;

whereas,

a face.tag is a list of interfaces (obj'c protocols) .

[11.9:

. this doesn't make sense for separation of { head, body }:

the clients don't need to know

where you're getting your body parts from,

so why post it on the head ?

(that's the contract with the client!) .

]

. primary feature of frame[impl'inheritance]

vs

supertype[polymorphic adt]

is

superclass is having slots that are callbacks .

[11.9: ie,

it's essentially a generic package,

and secondarily a data.type or type.class .

. it's saying that members of this class are

involved in generic functions;

ie, functions whose impl'details vary across individuals .

]

adda/oop/unifying class-based frameworks with subtype polymorphism:

10.29:

. to merge [the obj'c ideas of ] the protocol

and the frame [impl'inheritance]

with that of supertype

you're saying that new subclassers (reusers, b2b or wholesale clients)

can extend the code of the supertype;

ie, [by naming a type's supertype,

you are indicating ] how it decides who to call

and who to convert during biops [.?]

[.?] by including frames, ...

. the way ada uses "new,

is to allow reuse of interface while at the same time

indicating that the new type

is not assignment-compatable with the copied type .

[!] 0911/adda/oop/modular coercion

10.31:

. consider subclassing as [?] particular generic type

instead of being general

like in obj'c named [?]

eg, supertype`ext,

and the restriction make simpler [?]

like so:

you can only extend an operation, not override it,

meaning any code you assign to an operator

will be merged in a way that is

clarified by doc's and types;

eg

dealloc' by super does dealloc the entire obj,

but,

if your added fields are pointing to a non-trailer space

you need to add how to dealloc your special-needs fields .

. can you mix this idea with supertype

which mixes subtypes for biops?

in case of ext's,

the super doesn't know who its sublcasses will be;

also,

each subclass may or may not [know] each other

so when super defines a biop,

it means it'll treat its own in a private way;

and, if your subclass wants a say,

it can add it;

eg,

for is equal sub#1

says

if other in list of subs I know then case it, else false [.?]

--

. the start of this idea was from wondering if

one can avoid having to call super

for things like dealloc and init;

how can that be implit [{impl'd, implicit}?],

a recuring theme is how can lang design make simple

having control over staying abstract

and sharing impl details .

11.5: adda/oop/obj'c is complicated by c-syntax:

. adda can simplify syntax by assuming that

all code is sublacssing mananged obj's .

. in the mvc, eg,

there is so much complication

making c'symantics the default .

11.7:

adda/oop/impl'inheritance helps modularity:

. one reason to use impl inherit

is trying to reuse code without source code

. can class system stay true to metaphore of classifying science objects?

adda/oop/impl'inheritance's role:

. if impl'inheriting is not needed,

what is the best way?

. how are adda's and mac app interface similar?

. the impl'inherit of mac is meant to

hide and reuse a huge event loop:

this huge chunk is the same used in every app

except for the menu pointers and some added menus .

. the delegates (the functions you override)

are providing those pointers .

[11.9: generic package combined with subtype polymorphism

]

. the adda view is that your app is generally

a server that has an api (app' programmer interface);

and, that api is providing all menu details

(assumes other processes are getting

essentally the same menu as humans get) .

[11.8:

. if an app wants finer control over the gui,

it creates a plug-in for adde,

or it can provide an adde-replacement .

12.25:

-- adde being the user's agent that translates between

the api and the user's gui .

]

bk"mac`oop (schmucker 1980's):

. the Schmucker book on mac`oop

has a list of terms used by various systems

and equates them to the "(standard) terms .

. metaclasses are the obj's that manage classes

that in turn manage obj's that are class instances .

todo.adda/oop/terminology/review prior studies:

. prev'work on oop had good ideas:

the meaning of "(obj) is what represents state

as in 2 instances can't be at the same address

without also being the same obj

(but then a subtle bump into unions) .

. what they call obj is really the

subtype polymorphic adt instance .

11.7: web/adda/oop/terminolgy"{frame lang, ...}:

. frame lang

-- that was the name for dynamically building class relationships;

these can be considered a form of set .

-- this is the basis of AI (artificial intel'e)

building connections the way the mind does .

. the class.type has an adt like set.type

classes are sets that build their memberships by

having properties be true of a given obj .

. in oop theory, "(metaclass) means

the type'mgt for classes;

ie, metaclass : class

:: class : obj .

{meta, super} reminds of hyper -- the protocols .

. maybe method x should be impl' of x

(as in meta physics),

. maybe class could be like self in refering to

one's own type .

or simpler is: self is code,

whereas self`{class, type} refers to

other parts of self .

. multi.inherit sybtype is like serving multiple roles;

eg, html is a subtype of text and {graphic, codish}

( that is, it has multi-values depending on

the translation you want ) .

. multi-inherit sublclass simply means

the conjunction of multi-membership predicates .

11.7: bk.adda/oop/hurley`critical thinking:

. try to get vocab from roots (philosophy),

{meta, super, sub, hyper} class .

. terms are {proper, common} names or descriptive phrases

that serve as subj to a truth function {stmt, proposition}

thereby defining who the members of a class are

(a predicate class) .

. terms have {extensional meanings denoted class members}

or {intensional meanings conoted attributes} .

. english"(connotation) actually means

"(subjective connotation)

ie, what experiences the viewer associates with members of a class .

. terms are names of classes;

term`extension is members of class;

term`intension is property of class

-- conventional vs subjective connotations .

. increasing intension means adding more attributes

resulting in decreasing extension .

11.7: adda/oop/rev of terminology:

. adda needs a firm theory of types

to make sure features need not be bolted on later .

. parts of this process are:

( find all relevant definitions;

, find labels for those definitions from significant sources

, (wiki, apple, past notes)

) . however,

the point should not be to make everyone aware of every feature;

ideally, the point of sophisticated features like oop,

is that they make programming very easy .

. the perfect example is the oop version of number

where numbers can optionally be type-constrained

if you'd like to catch errors,

but you shouldn't have to think about how to combine subtypes .

. the main point of today's review is

knowing how to talk about the details .

Subtype_polymorphism

Parametric_polymorphism

Behavioral_subtyping

Duck_typing

Design_by_Contract

Covariance_and_contravariance_(computer_science)

Delegation_(programming)

Inheritance_in_object-oriented_programming

Comparison_of_programming_languages_(object-oriented_programming)

http://doc.cat-v.org/programming/bad_properties_of_OO

Covariance-and-Contravariance

. a part of terminology is lifecycle:

. when using the number.type,

the system finds the number`primitives .

. if there are other functions used with number-typed operands,

how is the developer adding those later ?

ie, how are add-on libraries associated with primitive libraries?

. ada solved this with hierarchical packages;

but how does it look when viewed from

how things are stored in folders,

and how binary modules can be relinked ?

the concepts (without the terms)

. describe new types either literally

or by describing one type in terms of another

X is a Y except for ...

describe subtypes:

. when reusing interfaces,

you have a choice as to whether the types are

assignment compatable .

. when reusing code`bodies,

you have a choice between getting auto'updates

or freezing the version .

news"subclassing as design by contract:

. when depending on generics by giving untyped symbols

[as param's] to a specific set of operations,

there is the concern that symbols are accidently similar

and the operands were accidently sent to the generic .

wiki says:

. subtyping is a relation between types (oop`interfaces)

whereas inheritance is

a relation between implementations

stemming from a language feature that allows new objects

to be created from existing ones.

In a number of oop languages,

subtyping is called interface inheritance.

. subtyping comes from defining a membership by properties,

if all type`properties are true for x,

then x is a member of that type,

a type`subtype includes all type`properties

and has additional constraints .

. by that definition,

type differs from classification in that classes are disjoint,

whereas types are merely abstract interfaces:

an obj' can be a member of any type

for which it satisfies type`properties .

. [oop] emphasized code reuse at the expense of

modularization;

and,

dynamic inspection at the expense of

static detection.

Therefore,

opportunities remain for applying important ideas

that hopefully will result in

even stronger engineering advantages for oop languages.

Behold the power of parametric polymorphism

Adding generic types to Java

By Eric Allen, JavaWorld.com, 02/01/00

[12.25: not sure how much the following

was influenced by that reference]

parametric polymorphism is generic:

. just apply abstract operations to untyped symbols,

then check the symbol's current type

when the operation is being performed .

. unlike the situation for subtypes of number,

there is a generic way for binary operations

to find a suitable method .

say x and y are the operands, and z is taking the result;

then by subtyping

they each can belong to several types: T{x,y,z}#i .

. so given the call f(x,y) -> z

the system has to find a method for f( Tx#i, Ty#i ).Tz#i

if that doesn't pan out,

the system has to find all the methods for f({T1}, {T2}).{T3}

and see if there are any conversions satisfying

Tx#i -> {T1} and

Ty#i -> {T2} and

{T3} -> Tz#i .

. this is much more expensive freedom than is likely practical,

but for completeness, this could be a low-priority option .

12.3: adda/oop/type as membership vs state`range:

. how to model type as member vs state

eg,

enum traffic has states (colors)

enum os has members(mac, pc, linux),

how to declare component of /os/./app/./cmd/ .

12.9: adda/oop/type`client`var's:

. recall the sort of type'mgt var's that are used for exceptions:

when a type is used by a subprogram (by declaring an obj' of that type)

it implicitely inherits a copy of var's that the type'mgt declares pub'ly;

it can then define how type-specific exceptions are handled

by modifying its version of inherited exception var's .

. the same type'mgt var's that are used for exceptions

can also be used as implicit parameters of a type's available operation .

. notice how these differ from the class var's of oop

which are shared by class members:

they are being owned by the client of the type,

who is also owner of a subset of the type's members

and these type'var's are shared only among that subset of type`members .

. the typical use for these are preferences in a paint program:

. each window is a new caller of the paint.type;

and then specific to each window,

you specify the brush`width, paint`color, etc .

. when you paint, that act means

calling the paint.function on the current file,

and that function also needs all those preferences,

so it gets them from the caller's pref's .

. a modular subprogram doesn't inherit environs

unless it's part of the interface (the contract);

whereas, a {private, nested} subprogram and a scope.block

do inherit environs,

which in turn inherit copies of type'var's

from any types they are using .

. there are several candidates for what constitutes a type's client:

a coprogram and a remote or modular subprogram are primary clients;

. 2ndary clients include nested functions and scope.blocks,

which are expected to inherit locals of the primary clients,

and could therefore inherit their owner's type'var's .

. how can 2ndary clients have the option of

either:

changing the super.scope's type'var's,

so that when the current scope ended, the changes would remain;

or:

getting a new copy of type'var's that are local to nested scope.block ?

. to avoid having to make such a decision for the user,

the naming conventions should allow a nested scope.block

to refer either to

its own copies of the type'var's,

with values inherited from either the type or the super.scope .

or,

to the copies owned by its super.scope .

. this could come in the following forms:

type`var -- the default (possibly partial) values of the var,

-- as provided by the type'mgt .

cur`type`var -- current scope's var

super`type`var -- inherited scope's var .

. the type'var's declaration by type'mgt can be partial,

meaning that a subprogram is required to initialize atleast the unfinished parts .

. after that, a subscope can implicitely be inheriting

the value of the superscope or explicitely reset values back to type'mgt's defaults .

. when a function gets a call,

the translation to c means that the type'mgt gets this call:

/type/2operand( operation, dst, op1, op2, [caller's type'var's]/.*),

which means that [caller's type'var's]/.*

is a pointer placed in a register

similar to the pointers to stack, and heap .

. any client of a type gets starts its act'rec' with a

declaration of a pointer that points back at the default type'var's,

or if it changes any of them, it has to make room for them all in a local record

and then have the pointer point at that record .

. using the paint example,

in an oop view, types are acting on a primary object,

and thus every obj' should have it's own pref's;

but, in the multi-oop view,

where the class defines membership as

any combination of types that are handled by the interface's functions,

then

the unit must be whatever corresponds to the user's window .

. or,

you could do both by having both {window, context} pref's,

where right-clicking on an obj' would bring up the pref's

that would apply just during modification of that obj' .

12.9: adda/terms/{self, sub, super}:

. the term"self should remain consistent with {oop, classification} theory;

an active program is an obj' in the sense of their being code and data

that seen as a unit;

but, to say that every subprogram has an idea of self

would be like thinking that a person's every subgoal had a self .

. intuitively, the term"self might refer only to actor obj's;

however, it might also be useful to reserve self as wordpart for meaning

the current location in aggregate having also {sub, super} parts .

. if that use of self doesn't work out,

notice that cur means the same thing, hence {recur, concur} .

. would there be some use within anonymous nested functions

for a {resub, resuper} as well as for a recur ?

. if resuper meant call your caller back,

how do you know what their parameters are ? .

12.9: adda/oop/type`client`var's:

. a type's client var's are a sort of implicit parameters

that it can offer on a per-client basis,

so that each client can customize what the type offers .

. if a client specializes it's client var's

or is required to define them,

then the change will affect future calls made by that client

without affecting other clients .

. the same affect could be had by explicit parameters

where a preference record ptr is passed to

to any calls handled by the relevant type'mgt;

but, the use of implicit parameters is more efficient .

. the client var' ptr is part of the current process context

along with the stack and heap pointers .

. just as a subprogram will access its locals

relative to the stack pointer,

a type'mgt operation will access any implicit param's

relative to the client var' pointer .

. part of the translater's job is figuring out

when there has been a change in type'mgt,

and respond to that by changing the client var' ptr

whenever that type is known to support client var's .

12.10: adda/terms/type`client`vars:

. what had been termed type'var's,

should follow the naming pattern set by

class`instance`var .

. type can be used instead of class

assuming all types are classes .

. the 3 fundamental state locations of an active type are:

type`mgt`rec -- class var's,

type`instance`rec -- instance var's,

type`client`rec -- parameter blocks .

12.14: todo.adda/oop/subtype needs review:

. instead of ada's x.subtype`= /type/

one type constant is "(in): hi.type`= in person;

. or could be better to use sub as a word part:

x.type`= sub./type/ .

12.19: mis.{adda, addn}/log/arf'd part of the adda type-in's:

8.28: adda/oop/private vs public/8.29: revisited:

"(. rather than have the public symbol"(sys)

being the activation record for the type`mgt,

..)

[but then at an arf'd part of the type-in's,

I couldn't make sense of this:]

. if type.classing access sys is still used for call

then just use the type's name;

[so then I couldn't find context for this:]

if the type is anonymous,

then it works something like anonymous recursion

where the recur.stmt is calling the enclosing subprogram .

SBGN (Systems Biology Graphical Notation)

8.15: news.adda/SBGN notation:

Systems Biology Graphical Notation (SBGN) project

. an effort to standardize the graphical notation

used in diagrams of biochemical and cellular processes

studied in systems biology.

doc's

spec's (pdf)

Abstract:

"(

Standard graphical representations have played a crucial role in

science and engineering throughout the last century.

Without electrical symbolism,

it is very likely that our industrial society

would not have evolved at the same pace.

Similarly, specialised notations such as the Feynmann notation

or the process flow diagrams did a lot for the adoption of

concepts in their own fields.

With the advent of Systems Biology, and more recently of Synthetic Biology,

the need for precise and unambiguous descriptions of biochemical interactions

has become more pressing.

While some ideas have been advanced over the last decade,

with a few detailed proposals, no actual community standard has emerged.

The Systems Biology Graphical Notation (SBGN)

is a graphical representation crafted over several years

by a community of biochemists, modellers and computer scientists.

Three orthogonal and complementary languages have been created,

the Process Diagrams,

the Entity Relationship Diagrams

and the Activity Flow Diagrams.

Using these three idioms

a scientist can represent any network of biochemical interactions,

which can then be interpreted in an unambiguous way.

The set of symbols used is limited, and the grammar quite simple,

to allow its usage in textbooks and its teaching directly in high schools.

The first level of the SBGN Process Diagram has been publicly released.

Software support for SBGN Process Diagram was developed concurrently

with its specification in order to speed-up public adoption.

Shared by the communities of

biochemists, genomicians, theoreticians and computational biologists,

SBGN languages will foster efficient storage, exchange and reuse

of information on signalling pathways, metabolic networks

and gene regulatory maps.

) .

concurrency in the news

8.15: news.adda/ROS (robot`OS)/summary:

. recently it was conjectured that the best chance for a

prog'lang that features concurrency better than threads

is going to be the use of a configuration co.language

which coordinates the modules of a system

while the user's prefered language defines the modules .

. now it's been reported by Kurzweil

that several university labs have settled on a configuration lang

for the problem of needing a standard platform for robotics development .

. there is currently an impl' for python,

giving that a healthy concurrency model,

and making it mixable with other languages .

. see ROS: an open-source Robot Operating System (pdf) .

. the project is hosted sourceforge.net .

12.16: todo.adda/e`promises/lots of interesting unfamiliars here:

http://wiki.erights.org/wiki/Promise

http://en.wikipedia.org/wiki/Futures_and_promises

In E a future is represented by a pair of values

called a "promise/resolver pair".

The promise represents the read-only view,

and the resolver is required in order to set the future's value.

Support for read-only views is consistent with the Principle of Least Authority,

since it enables the ability to set the value

to be restricted to subjects that need to set it.

In a system that also supports pipelining,

the sender of an asynchronous message (with result)

receives the read-only promise for the result,

and the target of the message receives the resolver.

Promise pipelining should be distinguished from

parallel asynchronous message passing.

In a system supporting parallel message passing

but not pipelining,

the message sends x <- a() and y <- b() in the above example

could proceed in parallel,

but the send of t1 <- c(t2)

would have to wait until both t1 and t2 had been received,

even when x, y, t1, and t2 are on the same remote machine.

The relative latency advantage of pipelining

becomes even greater in more complicated situations

involving many messages.

Promise pipelining also should not be confused with

pipelined message processing in Actor systems,

where it is possible for an actor to specify and begin executing

a behaviour for the next message

before having completed processing of the current message.

. a promise pipelining system has first-class promise values

when an argument to, and the value returned by a call or send

can directly be a promise .

12.19: news.adda/concurrency:

humans are actually quite adept at concurrency

. web for adda/0908's source of

"(humans are actually quite adept at reasoning about concurrent systems)

[PDF] Are new languages necessary for multicore?

ptolemy.eecs.berkeley.edu/.../CGO_Panel_PositionStatement_Lee.pdf

[PDF] Cyber-Physical Systems - Are Computing Foundations Adequate?

mesl.ucsd.edu/gupta/cse237b/Readings/Lee_CPS_PositionPaper.pdf -

Symposium on Code Generation and Optimization (CGO) ` CGO-2007 Panel

www.cgo.org/cgo2007/html/panel.html

dev.audio

7.24: addn/dev.audio/algorithms to shoot for

. the electronic music would be fun with a program that turns your voice

into orchestration with an algorithm,

there are a few patterns that are very pleasing without having to vary

as long as the root note sequece leading them is varying .

8.29: addn/dev.audio/some gear:

www.garageband.com/artist/Alexey_LSB

first the Korg N-364 workstation,

then I began to collect equipment for my homestudio.

Now there is:

Roland JP-8000, Korg N-364, Alesis QSR,

Mackie CR1604-VLZ mixer, Alesis RA100 amplifier, Alesis Monitor One monitors,

Echo Audiofire 2 soundcard.

And I dream about Access Virus TI and Alesis A6 Andromeda :)

10.25: todo.web/addn/dev.audio:

sampling is key word for compositing song parts .

benefits of ada's language design

7.14: co.net/reddit.com/dev.ada:

www.reddit.com/r/programming/comments/8ycxp/the_return_of_ada

fierarul:

These kind of studies tend to miss a lot of important stuff

beyond the error rate, etc.

For example, usually Ada/Lisp coders that would be involved in such an experiment

would be a self-selected bunch of experts

that tend to also be above-average programmers.

So, the good results aren't just the merit of the language

but the merit of having good programmers in the team.

LucasMembrane :

No. There was a college prof teaching programming who got about

none of his student teams finishing their term project

when he had them do it in C++

and got about all of them finishing it when he had them do it in Ada.

queus:

(Killer?) link?

addn(my reply):

. the reference is to here:

Welcoming Software Into the Industrial Fold

James M. Sutton, Lockheed Martin Aeronautics

http://www.stsc.hill.af.mil/crosstalk/2008/05/0805Sutton.html

. his reference is this:

McCormick, John W. Software Engineering Education: On the Right Track. Aug. 2000

http://www.stsc.hill.af.mil/crosstalk/2000/08/mccormick.html

7.14: co.net/linkedin.com/ada/Ada debated on reddit.com:

www.linkedin.com/groupAnswers

my comment:

. I found them a link pointing out that Ada

made students more productive than C did (appended below) .

. I hope to create a scripting language

that translates something like Ada into plain old C;

. it's believed that Ada is complicated for the sake of safety,

but the bulk of this rule complexity

really comes from insuring both safety and efficiency .

unix-c command line vulnerabilities

7.27: addm/command line vulnerabilities

. it was said that parsers should have minimal abilities,

because the C lang' allows buffer overruns that are then

running arbitrary code from the parser's space .

. notice that every c program can start by parsing a command line;

I wondered if this could be trouble .

pos:

. addx doesn't use that command line for anything;

everything happens through a config'file to start addx up;

then the addx command line uses etrees, not strings for param's .

minix vs Amoeba

news.addm/cap'based/minix vs Amoeba:

6.21:

. amoeba is cap'based?

amoeba was started by the creator of minix

(minix features high security via a microkernel);

but, amoeba is languishing while minix thrives ?

rationale:

. amoeba is a research project for a distributed os

(for doing supercomputing with networked computers)

while MINIX 3 is more important to the masses:

. well suited for Single-chip, small-RAM, low-power,

$100 laptops for Third-World children

and Embedded systems (e.g., cameras, DVD recorders, cell phones)

--. the lang that amoeba now supports is Orca,

7.7:

. why is cap'based security not an advertized feature of minix?

. the author of minix, Tanenbaum, wrote in 1990

that the use of cap'based security

was one of the things that amoeba did right .

. however, if small mem'size is key,

then it becomes significant that cap'based security

can be implemented as an optional add-on

using a cap'based programming language .

. another priority that minix excels at is being unix:

"(

amoeba's UNIX emulation will never provide 100% compatibility.

For example, the whole concept of user-ids and group-ids

is very hard to get right in a capability-based system.

Our view of protection is totally different.

Furthermore, Amoeba is essentially a stateless system.

This means that various subtle properties of UNIX

relating to how files are shared between parent and child

are virtually impossible to get right.

In practice we can live with this,

but for someone who demanded binary compatibility,

our approach has some shortcomings.

)

. nevertheless, the cap'based OS has advantages,

according to the authors of keyKOS,

"(

. There are no other mechanisms adding complexity

to the ideas or to the implementation .

It is worthwhile to contrast this approach

with the ring-structured security model of the Intel 80x86 family .

. The capability model is intrinsically more secure.

A ring-structured security policy is not powerful enough

to allow a subsystem to depend on the services of

a subsystem with lesser access rights.

Ring policies intrinsically violate the principle of least privilege.

In addition, ring-based security mechanisms convey

categorical authority:

any code running in a given layer

has access to all of the data in that layer.

Capability systems allow authority to be minimized to just that

required to do the job at hand.

Using a capability model offers significant simplifications in the nanokernel.

Among the questions that the nanokernel does not have to answer are:

* Does this user have the authority to perform this operation?

(Yes - if you hold the key you can send the message.)

) .

contextual password assistant

7.29: adde/contextual password assistant:

. when right-clicking in a password field

one option should be the password assistant .

8.8: adde/security/password keeper:

. if using the system pasteboard,

then during context switch, other processes can read your contents;

so then, there is needed a private copy

from user`pass.file to browser;

or, have built-in to adde atleast enought browser functionality for

handling https to banks, etc .

. if it's not practical to reproduce a browser

then the only sure route to security

is having user run other processes in a vm .

substructures and aliases

7.28: adde/alias handling:

. an alias is dangling when its target is deleted;

so, any delete operation should involve asking

whether aliases should be deleted also;

or, whether their appearance should be changed to reflect the dangling state:

eg, arrow symbols are changed to null, and name greyed .

. copying across volumes will copy the link .

. adde should also make a backup of link`targets;

and, also address complications of

duplications, and sharing updates, etc,

ie, when copying across volumes .

8.3: links are of 2 types:

. one is invisible so that any copy to the unit

is going to copy what is pointed at by the invisible link .

. the visible link is an url that means it is external to the unit;

and so should be copied only if wanting to copy multiple units .

. hence there needs to be some way to describe what a unit is;

like git identifies a project as the unit .

7.28: adde/subtructuring with modular skeleton:

. an efficient way to modularize a file

is to put the structure of it

(the table of contents with links to pararaphs)

in one file (the skeleton subfile)

so that changing a subtitle opens just the skeleton subfile .

pluggable system-wide param's

7.28: adde/pluggable system-wide param's:

. part of journaling is keeping track of

every change and option made on the system

in a pluggable form,

so that others wanting to help

can simulate your system by plugging in your journaled param's .

unforgeable dialog windows

go.adde/unforgeable dialog windows

7.7:

. whenever you get a window asking for permissions or a pass,

how do you tell who sent that window?

the platform's security system should have a window

dedicated to system messages .

unique filenaming

6.21:

. in a virtual fs (file system),

users can have any filename, virtually visible in multiple folders,

but the actual files are all named after

both the creation date, and the user name .

. the user is identified by the owner of

the super folder that all the files are in .

. if there is more than one user working on the fs,

the file names are unique because they reside in a user folder .

[7.7:

I got this idea from wondering how to share the addx project:

the project can have each author have their own version

in a separate subfolder .

. parts they decide to share are outside of the version.folders .

]

7.7:

. when working in a multitasking and multiprocessing system

with multiple agents,

the name is only unique when using both a timestamp

and the chain of command

(eg, a human starts an agent that employs another agent ...)

so then the name is human`agent#1`agent#2-timestamp

. the id#'s can stay small because a human user has

only a handful of employed agents,

who in turn have only a few employees

(service providers or libraries) .

footnotes

7.6:

. the purpose of adde`markup

is to have language that functions like html

but is a little easier to read and write .

. hyperlinks are prefixed by [@]

and in-line code is prefixed by [!]

7.6: adde/markup/perhaps obsolete?:

. markup is sort of an obsolete idea,

as the editor should be smartly helping you markup with a gui,

and then encoding the markup with wordcode

so that markup is a form of etree (ast) .

... then again:

. markup is not obs' because there should be

an ascii representation for all etrees;

[12.16: because,

the realities may require at some point

the use of a plain text editor;

eg, viewing work on pda's and e'book readers

for which addx is not yet available or not allowed .

]

6.12:

. footnotes are like hyperlinks,

so they should use the word[@]link syntax,

but instead of cluttering up the sentence,

it should use a sort of footnoting,

where the link info is deferred to the end

of the sentence, paragraph, or page .

7.7:

. here is a discrete way to do both hyperlinks and footnotes:

[((phrase to footmark))][]

. the box [] tells you that the previous lexical element

is a deferred link,

so then at the end of the line or paragraph

there is the "([@] { ...}) showing the list of footnotes .

. they are matched 1-to-1,

so that the nth [] is linked to the nth item in the [@]-list .

12.16:

. one problem ignored by the above idea

is that a good markup language will rarely conflict with

the language it's embedded in;

eg, you'll see "([]) a lot in c code .

dimensions as types

7.29:

. how to mix dimensions with (data)typing?

dimensions are like vector operators:

. they give type to a literal;

you could type a variable to be a dimension,

and then any literal assignment imlicitely has that dimension;

[12.16: eg,

num * inch /sec .

. length and time are a dimension of type number`real;

{inch, sec} are subtypes

of {length, time}, respectively .

. the subtyping allows conversions between

measuring systems within the same dimension .

]

10.17: sci.adda/unifying dimensions and map`keys:

. I've been confused in my use of "(dimension):

. in the expression (x cup rice),

rice is the dimension

-- like the unit vector when giving imaginary as (x i),

. this has a meaning equivalent to named param'association;

eg, complex could be either (y+ x i) or (y, i: x) .

. how does adda have types declare dimensions?

eg, how should num declare i to be

an imaginary dimension of complex?

. by the currently designed syntax rules,

i is a postfix operator: (real)i.imaginary .

. another view is vector notation:

C.type`= <> = x + y i

. that is, R is already defined as the reals,

and any postfixed symbols in that

are taken as declaring dim's .

[10.18: = .(real.R, i.R) ? ]

10.12: adda/syntax/conversion:

. if a function call doesn't need to use parentheticals as arg,

how is the parser knowing when a function is being defined?

. the first use of the symbol

does need to use a parenthetical

along with the dot-extension

indicating the return`type or obj`type;

eg,

id(...).type .

. if it wasn't dotted to a datatype,

and the symbol wasn't defined yet,

then there would be the ambiguity of

{ function(arg), biop(right.side`arg)} .

. notice that there could be another ambiguity

unless you're careful with your spaces:

. if the syntax for type conversion

is (expression).[new type]

then ( f(x).t ) means I'm defining f now;

whereas ( f (x).t ) means f( (x).t )

ie,

f is already declared as a uniop,

and it's being applied to an arg whose type

is being either coerced or converted to t.type .

. it helps to remember that during a function decl',

the parenthetical expression is part of the name,

so a function's name must be immediately followed by

the parenthetical expression;

whereas, during use of a name declared to be function,

the arg is already expected,

so you don't need paren's to shovel one in .

. this helps both to minimize syntax

and to use args that are

variables rather than list`literals .

10.15:

. when considering how conversions should be expressed,

keep in mind not only the syntax for applying it,

but also how the type.mgt will be defining [it].

. the type.mgt of the object being converted

may not even have the conversion routine,

so then the syntax should not be object-oriented .

. it's also important to

express them the way english-math already does

unless there is some higher reason not to:

that way is applying a dimension name

as a postfixed operator .

. a similar syntax for operator definition would be:

(x)f.y;

eg,

phys`dimension.type`= number;

length.type`= phys`dimension;

ft.type`= length;

inch.type`= length;

(x)inch.ft`= x/12;

(x)ft.inch`= x*12 .

11.9: adda/oop/dimensions:

. unifying the subtype polymorphism syntax choice

with that of dimensions and measuring systems .

. how are dimensions being obj's of classes?

. obj's of dimension have numeric state

[11.14: eg, in the view of that language,

length is a dimension,

and a measurement of that is an object .

]

. one dimension can have several measuring std's

eg, length has sublcass {metric, english, ...} .

[11.14:

. numeric models of a dynamic object system

include a number of dimensions that can be multiplied or divided

in order to express numeric relations .

. each dimension can have a number of measuring systems

and more can be added later by describing them in terms of

currently recognized measures .

eg, physics.system is

foot.length: 0.3048 meters .

]

bk.chem:

mass, length, time, vol.type = length**3

liter.vol = meter **3/10

density = mass/vol

. temperature, like density, is an intensive property

(doesn't depend on qty or mass)

whereas, vol and mass are externsive properties

. signif digits refer to measurements actually being uncertain +- some error factor

so shorthand is to give all signif digits with one digit of uncertainty;

signif digits include exactly one uncertain digit .

. sci notation standardizes placement of decimal

in order to make zero idicate significance:

eg, 100 has an ambigous range of uncertainty:

significant digits ?

( 3: 99..101

, 2: 90.. 110

) but 1.00 * 10**2 means 3 signif digits unambiguously .

. one reason the metric system has a name for every factor of the base

is so that choosing the right one can have the same effect as sci'notation .

eg, 1000 m rephrased as 1.0000 km

will have unambiguous significance .

(however, many order names have fallen out of use .)

[11.14: . to refer to exact amounts, don't use decimal points,

refer to floats with fractions ]

. so by being able to shift magnitude

the decimal point is always free to indicate the precision

(otherwise for large numbers with uncertain numbers of units,

there's ambiguity)

. rounding is defined in terms of significant {digit, figures};

mult and div result has the minimum of the 2 arg's signif'digits;

also, rounding {up, down} for 5 depends on {even, odd};

eg,

.25 -> .2

.35 -> .4

todo:

(see numana`text for alt's and caveates) .

. for determining signif'digits of an {add, subtract},

convert args to have same order

eg, 1 km + 1m

-> 1 km + 0.001 km

then km has zero decimal places,

so result must also have zero places:

= 1 km .

adda/oop/dimensions/automatic dimensional analysis:

. must make dimensional analysis automatic

. I can type x.ft assign it mm

and have the sublcass system will find the conversion auto'ly .

. this system is user {definable extendable} too;

eg, for adding new currencies .

. a dimension type has atleast one subtype

then other subtypes define a conversion from the original sub

eg the original in pkg physics is metric,

then english `physics is subclassing metric .

11.11: adda/oop/theory of dimensions:

[11.11: needs to handle dimensions from the supertype,

but also exensible later ]

ratio (n.qua, d.qua).type

density.ratio(mass, vol),

subtype(supertype.type).type

qua.type.

-- quaality has been synon with dimension, as in dimensional analysis .

rct vs polar coord's

bk.adda/physics:

velocity.ratio(distance, time),

acceleration.ratio(velocity, time),

force = mass * acceleration

density.type = mass /vol

vol = length**3

area = length**2

mass is resistance to acceleration

. unlike types, a symbol can have multiple concrrent dim's

that are not subtypes of each other .

. dim's are part of the number class

since numeric operations may encounter them as factors;

ie,

a number value consists of a qty

times zero or more dim's or their inverses .

. part of root physics system is the dim'set:

{time length mass money charge} .

charge is coulomb (C) = joule /volt .

Joule = length**2 / time**2 * mass

capacitance = C/volt

amp= C/sec

volt = joule/C

but an electron volt is a fraction of a joule

. electric field = force /charge (newton/col) or (volt/meter),

translation

7.6: adda/oop/registering operation clusters:

. for a type.class like Number

-- whose functions are operations (output is same type as input) --

the functions are often done in clusters

corresponding to expression trees .

. while the straightforward way to eval' an expr'tree

is to recursively eval' subtrees,

the efficient way is load all of the expression's inputs

into the type-mgt's register set,

so that you're calling type-mgt just once on that whole expr'tree

rather than for each operation .

10.23: adda/function calling vs stack loading:

. instead of num's type'mgt using functions,

adda uses a translate to calculator entry .

12.1: adda/translate/c`alloca:

. alloca is exactly designed for adda's

heap as stack-based trailer design!

but it's not std because of

not being easy to impl on all platforms .

adda/translate/c`calloc:

. by translating to calloc instead of malloc,

user is unable to invade privacy of others

who didn't zero their free's .

12.9: adda/concurrency/impl'ing a scheduler in c:

. to simulate multithreading,

the scheduler becomes the actual main program,

while the coprograms are translated into bite-sized "(scheduler slices)

which are then assigned to an array of function pointers .

. the scheduler can then sequence through several such arrays .

. if a subprogram is large eno' to need scheduler slicing,

then the scheduler has to include a calling mechanism

where the coprog's current location is placed on the coprog's stack

and then things continue as is typical of asm lang,

except that the instructions are scheduler slices,

and the return locations are refering to a tuple:

the subprogram's array,

and an index into that array .

. how does the translater know where to make the slices?

first, the adda user helps by finely decomposing the program

into subprogram calls, so then each call becomes a scheduler slice;

ie, the scheduler makes that call, waits for the return,

and then decides what coprogram to work on next .

. all loop bodies could become slices .

. all the function arrays have to use the same inout.type?

either the scheduler may need to impl' its own data stack anyway;

or things might be fudged with casts;

or, calls to functions of arbitrary arg's

can be boxed within std calls

where there is no arg or one having a ptr to environ, etc .

. in the asm model,

the call instruction handles arbitrary arg's like so:

the caller loads the stack with what the sub' expects,

then the sub' refers to all its locals as being

an offset from the current coprogram's stack pointer .

. to emulate this, a parameterized subprogram would

expect the scheduler's stack pointer to access the act'rec .

. the scheduler would start the call by

getting a new arg'rec with malloc,

pushing that onto the data stack;

then after calling, it would free arg'rec it popped from the data stack .

12.26: adda/translation/handling c's small linker namespace:

. the ada`package can be impl'd in c

by exporting a record of function pointers .

so then the linker's small name space need contain

only the names of packages .

12.26: news.adda/security/Flawfinder for c:

. flawfinder is a program that examines C source code

and reports possible security weaknesses (``flaws'') sorted by risk level.

It's very useful for quickly finding and removing

some security problems before a program is widely release

safe pointers

7.6:

. pointers all include the id of the scope they are part of,

so that when asking a type-mgt to make an assignment to that pointer,

it can tell whether the scopes differ,

-- looking esp'ly for when a local

is being assigned to an external --

and, then things can be arranged to guard against dangling pointers .

. this needs to include the idea of monads

where each external has a local proxy,

and then it's the responsibility of the run-time system

-- not the type-mgt --

to worry about dangling pointers .

8.9: adda/pointer/types of addressing:

. pointers are addresses;

here is a catalog of addressing types or dimensions:

. persistent pointers can target the name, location, or contents:

{ url -- name of path and file

, filename -- any object or location having that name

, file obj -- the particular object regardless of changes in filename or location

}

. non-persistent addresses -- specific to a time or space domain:

( these are pointers that are indexes or offsets of a private [or local] heap,

ie, a heap used only by a particular

process, type, type.class, or object .

)

. pointer ownership:

clients can refer to obj's by pointers

and servers can use private pointers to structure their obj's .

CAR (current activation record)

7.5:

. a var`init associates a var`instantiation

with a particular subroutine or block activation

(stacked activation record, or act'rec)

. at the end of the act'rec (when the stack gets rolled back),

a type-class gets another call to close

-- this doesn't need a parameter because it implicitly refers to

the current act'rec .

this is done without the programmer,

by translating var creations into these {init, close} pairs of calls .

7.6:

. when a subprogram starts up,

it needs space for its own locals,

and when done, then it needs to release its own locals .

. this space typically comes from a combination of

the system's stack and heap .

. the elaboration of a declare block or subprogram call

results in the creation of a new scope,

meaning it creates a new activation record on the stack,

referred to as the [current activation record] (CAR) .

. for the sake of modularity,

the computer's heap space should be decomposed into

separate subheaps for each subprogram call .

. this will make it easy to both get the memory back

after the subprogram returns,

and associate each object with a particular subheap .

. so then, in its simplest incarnation,

the CAR on the stack is simply a pointer to a subheap;

and, when the subprogram returns,

it can simply dispose of its one subheap

rather than asking each involved type-mgt

to recycle its own objects .

. when a scope creates a new variable of type"T,

it's calling T`type-mgt to implicitely use CAR space

to allocate a piece of the subheap and initialize it .

unifying contracts, permissions, and capabilities

7.5:

merge:

. dynamic permission setting .

. sometimes a var needs {read, write, exe} status under prgm control;

eg, locals of a program

which are external to that program's subprograms

can specify which subprogram can have what access .

. it can create local names dynamically

-- a filesystem that is local to a program .

. it can either statically declare var's as const,

or dynamically set permissions like this:

obj`access(user: rwe) .

. imagine that your program controls variables

with exactly the same power with which you control files:

not only do you have creation-time or compile-time control

of how a variable can be accessed;

you also control at run-time, whether to create a new variable,

what to name it, and how it can be accessed .

. this is thinking like a lisp programmer:

the simplest path to automating your intelligence

is to give your automation

all the same controls that your intelligence has,

so that you can code it just the way you do it .

. it is also simplifying a language

to unify all similar features .

. the next step is moving from permissions to capabilities .

. rather than obj's saying who has what access;

the agents come with contracts that explain

what access they need,

and then the system insures

that they stick to their contractual access limits .

7.6:

unifying permissions with cap's is part of oop contracts,

simple objects like Number have an empty contract:

they don't interact with anything .

. complex contracts include files used, files kept,

other objects or systems being communicated with,

info being communicated,

7.7: adda/dimensions of contracts:

. contracts are usually literals,

an immediate value that the compiler can use,

but they also need to be parametric (a parameter of generics)

and inheritable from employer .

7.23: adda/capabilities:

. adda does not have to be inefficient in its total control of resources:

its allowances are set as read-only pointers .

. the capabilities are expressed as

read-only pointers to the allowed functions .

. if capabilities change,

the pointer becomes invalid,

and the process then throws an exception when it tries to use it .

. after looking at the modularity of rsbac,

I was thinking that was really inefficient,

but combined with my idea for adda here,

the expensive decisions have to be made only once,

apon declaring a need for the object,

and often that can occur during compilation .

--. some notes on rsbac:

Rule Set Modeling of a Trusted Computer System,

Generalized Framework for Access Control (GFAC)

. the clear separation between

Access Enforcement Facility (AEF),

Access Decision Facility (ADF)

with

Access Control Rules (ACR)

and Access Control Information (ACI).

The AEF, as part of the system call function calls the ADF,

which uses ACI and the rules

to return a decision and a set of new ACI attribute values.

The decision is then enforced by the AEF,

which also sets the new attribute values and, in case of allowed access,

provides object access to the subject.

The Access Control Enforcement Facility (AEF)

intercepts every security relevant system calls,

compiles them and performs a request to the

Access Control Decision Facility (ADF).

The ADF will ask every Decision Module

for its opinion on this request.

The answer from every module is combined by the ADF

with a restrictive metapolicy,

giving a final answer that is sent back to the AEF.

The object is accessed normally

if access has been granted previously .

If everything went without denial or error,

the AEF sends a notification to the ADF.

The ADF tells the modules to update their attributes

from the data structures.

The ADF sends back an acknowledgement to the AEF.

Control and optional data are returned to the process.

7.7: addm/unifying cap's with permissions:

. great, I found a good description of a capability!

now I can figure out how it's related to file permissions .

. in the simple permissions system,

your acct is associated with either the user or admn role;

and, when you ask for a view of available files,

you are handed virtual cap'keys that depend on your role:

admn's have free access,

and users get what the admn's give them .

. any program your role uses will inherit

the virtual cap'keys due your role .

. in the role-based access control system,

there are special groups that users can belong to:

{ power users, backup tech's, ... various special roles};

so then file access depends on what group

your acct is a member of .

. again, you have to be careful of what role you're playing

because the tools you use will be inheriting your cap'keys .

. in a cap'key system,

a program will not inherit your role,

instead the system will inform you that your new program

is wanting access you haven't given it,

and then provide you with a menu of all the cap's you have:

per-folder permissions, net activities, ... .

7.14:

. I had conceived the cap' problem by this typical situation:

I have an app that should do a job on one object and not other .

. now is it ok if this app calls another app to do something with this obj?

. my assumption was that I can't trust this app anyway,

so I minimize its destructiveness by saying whatever it does

will only happen to the selected obj;

but there must be some limit to this:

if it can call something that can transitively call on-line,

my obj -- with personal info -- just went online .

. this is called the confinement problem,

and it's solved the way you would think:

your app needs permission to reach on-line

and to reach any other app that may transitively reach online .

. revocation:

how can you revoke a cap'key given to an app?

you need to send it a proxy, like a pointer,

but instead of leaving the pointer dangling,

it creates a situation where

the proxy's target has been instructed to

deny any additional services .

decentralized extensibility

news.adda/decentralized extensibility:

7.2:

. decentralized extensibility means

allowing parties to include their own elements or attributes in content

without risk of name collisions (whether those names are the result of a

consensus process or not).

esp (entire software process)

6.18:

. the software process was thought to be primarily dependent on

mgt`practices;

later it was determined that personal and team processes

were also vital to software quality .

. entire process = { mgt, team, personal } .

. "(esp) is an interesting initialism

because esp (extra sensory perception) touches on a dimension of psychology

that is deliberately overlooked

due to it's being outside the bounds of experimental validation .

speed reading

psy/speed-reading:

6.7:

. the 2 issues with speed reading are:

motivation -- how to stay interested in communicating;

and, familiarity -- before one can read idioms as such

rather than subvocalized words,

one has to be familiar with the sublanguage, the jargon, or author ecentricities;

so then, one path to speed reading

is simply brute-force being well-read .

. another key task is filtering:

given my primary goals,

how much of this page is worth stopping to vocalize;

sometimes it can help just scanning pages to give your subcon'mind a taste,

hoping for inspiration upon a 2nd pass .

em objects' connection switching

6.2:

. if em (electromagnetic wave) obj's exist independent of

the masses they connect,

are they vanishing when the view is obstructed by other obj's ?

. certainly the em net is only between adjacents

because obstructions can obstruct all em energy transfers .

. think of em's as existing per atom

to connect with any reachables .

[6.3:

. or think of each mass as having an infinity of infinite waves

in infinite directions,

and the waves of atom are virtually connected to the waves of another

because the wave in one em obj' is inducing a wave

in nearby parallel em obj's . ]

7.24: news.phy/light as particle and wave:

The wavelength of light ranges from hundreds of miles for long radio waves

to one millionth of a nanometer for gamma rays [graphic].

The energy of light is inversely proportional to the wavelength,

such that gamma rays are a billion billion times more energetic than radio waves.

The classic example of particleness is the photoelectric effect,

in which light hitting a metal sheet

causes electrons to fly out of the surface.

Surprisingly, light longer than a certain wavelength

cannot liberate electrons, no matter how bright the source is.

. a strict wave theory of light cannot explain this wavelength threshold,

since many long waves should pack the same total energy

as a few short waves.

[hello?]

. the Einstein`particle theory never replaced the wave theory,

since only waves can describe how light interferes with itself

when it passes through two slits .

8.20: phy/Faster Than Light Travel--Concepts and Their "Problems":

http://www.physicsguy.com/ftl/html/FTL_part4.html

. when I saw the title to this,

I thought there should not be any problem with going faster than light speed,

. it is speed, and what are the limits on acceleration?

. you need to show that the energy needed to accelerate the fuel

is going to mean there is not eno' fuel to approach light speed .

. if you could catch fuel on the fly by concentrating light;

but how can that fuel cause acceleration in a vacuum?

constitution for federated development

6.18:

. after reading about getting over benevolent dictating

I began to think about ways to make forking part of the process .

. each contributer would have their own root-level subfolder

within a familiar svn (subversion) repository .

. this would virtually turn svn into a git or mercurial

in that the primary design goal of git was to facilitate forking,

and make that a religion rather than a problem .

. svn can be used to talk with eachother via

writing comments and suggestions in each other's forks .

. you are not expected to keep these comments in your code

but you give them a quick review and either roll changes back

or merge the changes by following the advice .

. contributors can have various combinations of

both the implementation and interface forks;

eg,

interface forks will be for trade-off's between

efficiency and security,

while an implementation fork may be used for

practicing a different coding religion (language, format, ...);

[12.15: or,

they may do the documentation after the coding rather than before,

whereas, a major reason I started my own project

was that I wanted documentation written first

and I wanted the code written in my own language .

. another reason to fork is the interface religion:

eg, the mac strives for consistency through dictatorship,

whereas, the constitution of addx requires that

the user have intuitive access to an interface editor .

. the shared.subfolder would contain the constitution;

this includes any contributor requirements .

. for the most part, sharing between contributors is done by

viewing the code of other forks,

and linking to (rather than copying)

the modules of those that are either doing a great job on their own,

or are willing to negotiate mergings .

]

. if the forks can share much code,

then there is no issue with forks taking up limited resources;

otherwise, the shared.subfolder can point to where

various forks have migrated .

[12.15:

. the shared.subfolder will introduce each interface fork;

and, explain the extent to which the modules from various contributors

can be used interchangeably within a selected interface .

]

. the shared system described by the constitution

makes it easy to select a combination of modules

and have the system built from source without giving the user

headaches for making choices .