Aquarian Steady State theorem

12.31: relig/aquarian/ElectroMagnetic Relationism
summary:
. for the dawning of the Aquarian Age,
I'm publishing a new version of 1992's
Physics/eternity/How a Star is Created:
. the vanilla "Steady State" theorem was disproved;
but, it's a perfect surname for a cosmology that
 supports the Final Anthropic Principle;
so, in honor of the 2012 festivities,
my cosmology will be referred to as
the Aquarian Steady State theorem .

the Screw U. principle:
. a new twist on developing this subject
is the theory that all real research on it
is stifled because it inexorably leads to
an understanding of Directed Energy Weaponry .

binary operator support for evolvers

4.25: adda/oop/biop'support for evolvers:

. unlike polymorphs such as type"number,
when an evolver gets a biop (binary operation),
it doesn't have a type'mgt that knows
who all its subtypes are,
so it doesn't know how to do conversions,
and can't delegate a biop call
to a particular subtype .

. one approach, though not generalizable,
is to have all biop methods be defined by
the root type,
and defined in terms of unary operations .
. all evolutions of that root type
would then inherit a working biop,
even if they had defined their own unary op's .

. the unary op's should provide code too,
just to be consistent?
ie, evolver subtyping involves complete impl'inheritance ?
[4.30:
. it should be up to the individual root.type
as to whether or not it chooses to
share a given method;
but if it wants the biop's to work
the way they do for polymorphs,
then it will provide the methods for all biop's .]

. a dynamic scripting approach,
like one might expect from a lisp system,
would be where all evolutions or subclasses
are allowed to read and modify
a supertype's biop-managing script .
. a subtype would register itself
and complete a table:
subclass x subclass x biops;
or, do whatever other rescripting was needed
in order handle the various combinations of subclasses
that are sent a biop message .

. a strategy for how to design evolvers
is to keep in mind why inheritance is good here:
it offers a form of type-checking
along with interface-based programming .
--[4.29: it offers nominal in addition to
structural subtype polymorphism (generics).]
. generics is when any type will do
if it supports the same interface
(I call these typeless obj's "(generals)).
. nominal type checking includes
the given type'name and all its descendants .
1130:
. the type'tag points to type'mgt
which is a node in a tree (or lattice);
that node has ptr's to all sources of inheritance .
. the 2 arg's of a biop must share
one or more supertypes,
and one of the supertypes must support that biop .
. if more than one?
[4.29: as when using multiple ada`packages,
the biop could be qualified to indicate
which node in the type.class lattice
the operation should be executed by .]
[4.30: qualifying an infix operator
could look rather confusing;
another option is raising an exception when
multi-inheritance is getting ambiguous .
. Ada05 allows multi-inheritance only with
interfaces (methods are not inherited,
and there's no concept of a biop).]


4.29: adda/oop/evolvers supporting biop's:

. what if an evolver wanted to inherit from a polymorph?
as long as adda promotes generics or interfaces .
[4.30:
. inheritance that expresses a
nominal subtype polymorphism
may not be good for contract-based prog'ing:
. types that support the same interface
could be modeling very different things;
so there should be a distinction made between
whether the model or the interface is supported .
eg, when I say the formal is a number,
I probably don't mean
the assigned obj'should do clock arithmetic
-- even if the interfaces are the same .]

. how does it support biop's ?
it needs to ask both arg's who their type'mgt is,
and see if they have a common superclass,
then see if any of them have a method for that biop .
but, num is a closed type, (not an evolver):
the biop it supports is not tolerating any
unrecognized subtype names .

. similar to the idea that there are
separate inheritances for interface and impl',
not every interface inheritance
has to imply the type is compatable with
the one it inherited from .

. just as polymorphs have some way of cooperating
in order do binary operations on various subtypes,
the evolvers need some universal way of describing value:
ie, the one job of the root.type
is having a way to define the supported values
in terms of some composition of public types;
[4.30: ie,
a subtype doesn't have to reveal how it stores a value,
but it does need to support exporting of a value
in some public form,
similar to offering a printed version
but instead of exporting as text,
it would be an efficient binary form .]
. for example,
number could describe its polymorphs
as an evolver would:
instead of subtypes knowing each other
and providing conversion routines,
the root.type, number,
could define a record of integers
(or a pointer to symbol in one case)
that describes all the parts of any number:
( mant'int#, [irrational]/ -- mantissa
, mant'frac'numerator#
, mant'frac'denominator#
, exp'int#, exp'frac# -- exponent
, sign'int#, sign'frac# -- large for complex numbers .
); [4.30:
. for types that are not numeric,
the root.type could express itself as
some tree of certain classes of symbols,
like the way english can be described,
with a grammar and a vocab' .]

. is that idea useful for the problem of
integrating popular notions of oop with biop's?

. the obj'c oop is assuming privacy from
even subclassers, not just clients;
therefore, any biop's must be defined in terms of
the superclass's unary op's .
. as shown by class"numbers,
there will be situations where only a
universal value format will be useful:
the biop will ask both arg's
to convert themselves to universal,
and then after working on a pair of univerals,
the biop can ask the receiver
to convert the universal to the type prefered;
[4.30: ie, within an evolver class,
one of the subtype's assignment functions
is expected to accept a universal-formatted value .]

structural subtype polymorphism

4.25: adda/oop/structural subtype polymorphism:
. in addition to polymorphs and evolvers
there are generals, where type is not named;
instead,
the given obj' must support the same operations
as expected by the formal symbol
that the obj' was assigned to;
and, in order to show
where it's getting this support from,
the obj' must carry a type.tag;
this would be in addition to
a possible subtype tag that the type'mgt would use
to discriminate between a polymorph's subtypes .

polymorphic vs evolutionary subtyping

4.23: adda/oop/polymorphic vs evolutionary subtyping:

. the crux of subtyping is being
compatable with multiple types;
structural subtyping is allowing compatability between
any interfaces that share operations having
the same name and parameters;
nominal subtyping is where compatability is declared:
a subtype is compatible with its supertype
because it defined itself as supporting that supertype .
. the 2 types of nominal subtyping
are tentatively named here:
polymorphic subtyping, and
evolutionary subtyping .
. the term polymorphic refers to a single genome
that results in individuals of varying form;
eg, drones, queen, workers .
. evolution is about extending the capabilities
that were inherited .
. when considering the design of syntax for oop,
I noticed a difference between
{polymorphic subtyping (polymorphs)
, evolutionary subtyping (evolvers)
} that would cause their syntax to differ:
. the polymorphs are exemplified by the numbers,
which include the subtypes {Q,R,N,Z,C,...}.
. an obj' of type"number needs to recognize
all the binary operations (biop's)
that are recognized by any of its subtypes; [1]
this implies that a subtype's set of biop's
can never be an extension of
its supertype's biop set
-- it must instead be a subset .
. this is in stark contrast to evolvers
where a subclass's set of operations
come from not only inheriting those of superclass's
but also by declaration of new operations .
1:
proving (using number as an example)
the supertype of a polymorph needs to recognize
the union of all its subtypes' operations:
. any time a binary operation occurs on
on an arbitrary pair of subtypes of number,
the most general response must be
to ask the supertype how to handle
any combination of subtyping in
{Q,R,N,Z,C,...}x{Q,R,N,Z,C,...} .
. even though there may be biop's
that only one subtype can perform,
in the general case
-- with dynamically changing subtypes
and user-defined polymorphs --
the only modular approach
is to leave it up to the supertype
to decide on whether a pair of subtypes
can legally be used by a given biop .
. the alternative to modularity
is to reprogram the compiler
to know what the supertype's job is,
so that it can supply that code implicitely .
. that might make sense for numbers,
but can compilers be changed in the general case?
(eg, with plugins); otherwise,
polymorphs need to put that code
in their supertype's body .

. the compiler should be able to use
the supertype's body, in a high-level way,
for optimizing code;
eg, if every twin pair (M,M) results in
delegating the implementation to M's method,
then in-line code could include
a run-time check for whether a pair were twins .

subtype polymorphism replacing polymorphic records

4.22: adda/oop/subtype polymorphism replacing polymorphic records:

. the example in [cocoa patterns].book/hierarchy
of using a graphics tree to express subgraphics
reminded me of how expressions use trees:
. generic trees are intuitively implemented as
variant records, (I'm not sure why these aren't called
polymorphic records ...)
and, this had me realizing how oop subclasses
are using their subclass tag
as a variant record discriminant:
[4.28: for example,
an expression tree has an eval operation
for both the branch and leaf variants
of its variant record structure;
therefore, it's a candidate for replacement by
an oop structure:
the branch subclass's eval
has to eval all args's
then apply the given operation;
the leaf subclass's eval
has to return its immediate value .]
. in both the case of oop and of variant record,
the low-level implementation could involve
a tagged record:
a record where one of the fields
is a code indicating which variant or subclass
the current state belongs to .

. to see a record as an ADT (abstract datatype),
imagine its list of components rephrased as
the operations that come with those components .

. show how oop's subtype polymorphism can save space
the way a variant rec's polymorphism can .
[4.28: variant rec's assume
that the size of all variants
is known at compile time;
and if all the sizes are known to be
approx'ly the same,
then the implementation might use
an immediate placement
rather than a pointer .
. among oop cases, it's true for polymorphs (eg, numbers)
that the size of all variants is known at compile time;
but not generally true for evolvers
(because they can evolve after compile time)
so then, polymorphs can benefit from a
tag system that can indicate
whether the obj's placement is immediate
or found by a pointer .
. on the other hand, oop's polymorphism can be
a time waster:
if half the instances
implement an operation as null,
then it would be more efficient to
case the tag
and make the call only when the instance
supports that operation;
that, in fact,
is why oop allows both styles:
oop can do anything a variant record can
by allowing a client to ask an obj'
what subclass or variant
it currently belongs to .
. summary of variant discrimination
vs subclass polymorphism:
. every node visit can either case the tag
in order to decide on operations to apply;
or a visit can simply
use those operations that are
supported by every subclass .
so, when you ask an oop obj' to do an act,
you're asking a subtype
to do its version of the act .]