inferred typing

11.12: adda/types/inferred typing:
(reviewing evlan's type system draft)
[@] 11.10.31/news.adda/lang"evlan/
evlan.org describes many addx features
. the reason you want to infer types
is so that you can have an efficient run-time;
if you don't care about that, as when prototyping,
then oop can be checking everything at run-time,
and both the coding and the compile times can be very fast .
. perhaps another reason to infer types
is so that you can warn users when oop might not help?
-- see the obj'c text's explanation of
why you don't want to type everything weakly
(as a pointer to anything);
basically it's because obj'c offers
so much freedom with deferred linking
that the compiler can make only the most general
inference:
if you don't mention a constraint
then the compiler has to assume you need
an unconstrained type for the purpose of
linking to future objects of unknown type .
. prototype developers and even production coders
like oop especially because it lends itself well
to such typeless programming,
ie, specifically avoiding type constraints by
letting the objects themselves decide whether
they understand a certain command .
. when you get into binary operations though,
(ie, pairs of objects -- and pairing is where
the dancing gets interesting )
then typeless programming is not so useful,
so typing is the only way to do what I call oop
(the classic example of oop
is the polymorphic type"number,
a class of subtypes including integers and floats;
ie, integer and floats can be playing well together
only because they are declared as subtypes of
the same type supertype, Numbers ).

classification by superset decomposition

5.15: adda/oop/type cluster/
templates for subtype association:
[6.1: mis:

"( . having types specifying which subset relations exist
doesn't neatly show the relation of irrationals

)??
irrationals are simply the reason
why some reals are not Q's !
. what is the purpose of knowing how they are related?
isn't it just to know type compatibility?
if you produce an irrational,
you call it a real,
and if you didn't want symbolics
then you'd call it a float .]

. the mgt for type clusters(eg numbers),
may have some reusable code in that there are
many type clusters in which the subtypes have
values that are subsets of each other; eg,
N subsets Z subsets Q subsets R subsets C .

. number is also an example of there being
another way of describing subsets:
superset decomposition
(showing how a set is composed of other sets).
. saying which subset relations exist
doesn't neatly show the relation of irrationals
(ones not expressible as a ratio, and
having an infinite and non-recurring expansion
when expressed as a decimal).

N = 0.. infinity;
Z= {+1,-1}*N;
Q = {Z/N, Z};

irrationals = {pi, e, 2**(1/2), ...}:
pi/4 = +(^i=0...infinity| (-1)**i /(2i+1) )
pi/2 = *(^i=1...infinity| (2i)**2 /(2i)**2-1) )
pi = 4 / (1+ 1**2 /( 3+ 2**2 /(5+ 3**2 /(...)))
e = (1+1/infinity)**infinity .

R = {Q, irrationals, repeaters}
C = {i*R + R, R} -- i = (-1)**(1/2)

menu systems for compound documents

4.2: adde/menubar`contents:

subdesktops:
. a compound document is one composed of
trees and tables of hyperlinks, text,
graphics, numbers, and any new types
for which there are app's to drive them .
. it's as if there are
many app windows in a single document
just as there are
many app windows on a desktop;
therefore,
a compound document can be thought of
as being desktop within a desktop,
and could thus be called a subdesktop .
. adde can then be called
a subdesktop editor .

review of mac`menubar:
. there are various places to put a menubar:
# the mac`menubar is at the top of the display;
it contains a menu belonging to
whichever app is controling the current window;
# many non-mac systems have, instead,
window-specific menu's:
. the app's menu would be located at
the top bar of each window belonging to that app;
whereas the display's menubar would contain only
system-wide menu's (eg, admin' functions,
app's launchers, and a file finder) .
[5.3:
. the mac`menubar has a list of co.menus
(co.menus are side-by-side,
just as submenus are nested under other menus
).
mac's standard co.menus include:
( (system`name)-- about system, param's, updates;
, (app`name) -- about this app, param's, updates;
, file -- interactions with perm'storage;
, edit,format -- modify the currently open file;
, view -- customze how content is displayed
-- (doesn't modify the content);
, (app-specific menus, ...)
, window -- arrange or select the app's windows;
, help -- for both system-wide, and app-specific .
)
. mac'menu's are expected to be complete
in order to represent what the app does;
5.4: eg,
mac`finder's window has a search box,
but it also has this menu:
finder`menu#file/find .

mac`menu#edit:
[5.8:
. mac uses the edit.menu for
anything related to document modifications,
including select, as well as {copy cut, paste};
and, any service that optionally edits:
eg, find(and perhaps replace),
or spellcheck(and perhaps correct) .
. however, there may be other co.menus
that also provide edits;
eg, mac's textedit has menu#format
which modifies the selection's {font,style,...} .
. another editing co.menu is used by vmware,
(if you think of a virtual machine as a document);
vmware`menu#[virtual machine] is used for
pref's that apply only to the current document .]

[5.3: 5.8: a menu#edit for subdesktops:

. mac provides 2 ways to select data:
# edit#menu/select all
# use the mouse to define a subrange .
. therefore,
because subdesktops are compound doc's,
with a variety of datatypes combined;
there are more ways than [select all]
to select things by menu:
you can also subrange by type .
. whether for simple or compound doc's,
there should be a [select some] item
in which a given truth function can define
a subrange of the {moused, typed} selection .
. in sum, selection subrange provides,
for each type in the current document,
a checkbox and an optional constraint parameter;
eg,
[x] is .txt except [find "(todo)]
[ ] is .jpg except [ null ] .

. this can be integrated with the
[select all] like so:
[select all] brings up the
[select some] dialog,
showing you the list of types
with all possible types selected;
so if no subrange constraints are needed
then just pressing enter
works like [select all].
. if the new user doesn't appreciate a dialog,
the dialog can have a checkbox to
"( map this [select some].dialog
to command-shift-A ).

. the currently moused selection
is mirrored in the menu selection:
if a selection is already made,
the [select some] dialog will
reflect that selection state
by checkmarking only the types
that are currently selected .
]-5.8
[5.4: the dynamic menu:
5.4: 5.9:
. mac`menus can have dynamic content:
ie, they will grey-out any menu items
that aren't applicable to the current selection .
. fully dynamic menus can also
add and remove submenus .
. compound doc's have document-specific
combinations of datatypes;
therefore, fully dynamic menus are required
in order to display all the type-specific menus
of all the datatypes contained in the current doc'.
[5.10:
. if mac`menus weren't fully dynamic
then adde's mac`menu could be for adde-wide operations
and then the edit.menu would have a
[type-specific operations ...] item
that would open an adde-designed menu system
which can then support full dynamism .

[5.4: 5.6: 5.8: merging app menus:

. there are several ways in which
the menus of a doc's datatypes
are merged into a single menu system:

# simple:
. a submenu is named by type,
and selecting that command will then
be applied to components of that type only;
other types will be ignored .
. when on the mac,
these type-specific menus would be expected in
menu#edit, along with [select all] .

# subtype polymorphism:
. an example of this is the supertype: number;
its menu items apply to all numeric subtypes
(int,float, Q,Z,R,C) . [5.10:
. the typical supertype menu
would list any operations affecting all subtypes,
and would then have submenus
representing each subtype, and containing only
subtype-specific operations .
. subtyping is concerned with interfaces
rather than implementations;
so, if a float happens to have an integer value
it retags itself as being an int;
however, since ints are a subset of floats
something constrained to int
will never have a chance to
similarly retag itself to float .]

# representational polymorphism:
. representations include
{ value implementations,
, graphical image,
, and programming language image
( adda-representation text )
} eg,
. when numbers are selected,
I can either bold-format a numeric's text,
or I can add the numeric values . [5.11:
. adde must either detect when types use text,
or types must declare this;
types may want to suggest a preference
that would explain to the user
why the preference exists;
the user can overrule any preference
after oking a purpose alert .]
[5.10:
. if an app is using text to represent its content
then a text styling menu
would apply to that app's datatype
(of course, the other text-modifiers
do not apply because
the text represents a type state
not just strings of characters).
. the user may want to vary the text styling
depending on whether the app's mode is:
# show value's graphical image
(might not use text)
# show value's adda-representation
(might be unavailable*)
# show value's implementation .
*:
. while every datatype must be
implemented in adda;
that type's values are not required to
have a written form (adda-representation);
for example,
streetlight.type = (red, yellow, green);
the intended image of the value red
is an icon that is colored red,
the adda-representation of the value red
is the text "(red);
and the implementation of the value red
is the integer: 1 (assuming the
default encoding of enums starts with 1,
and seeing that red is the first value).]

# generic polymorphism:
. the [all types].submenu shows
what operations of identical name
are recognized by every type in the selection
even if each type's authors had no idea
that they were naming their functions the same . [5.11:
. this would include the case of subtypes
where a supertype's interface is shared;
thus it involves supersets of subtype polymorphism .]
]-5.4: 5.6: 5.8 .

[5.4: the editable menu:

mac`menus are not expected to be user-editable;
but they can launch editable windows .
. in adde's menu-editing mode,
the user has access to 4 menu systems:
# the original menu tree;
# the original keymap;
# the user's version of the menu tree,
# the user's version of the keymap:
. the keymap is a table representing the keyboard
labeled to show each key's function .
left hand . . . . right hand
[][][][high].[] [].[high][][][]
[][][][home].[] [].[home][][][]
[][][][low ].[] [].[low ][][][]
. it's colored to make it graphically obvious
where the home key's row and columns are;
and, users can change the graphics:
the colors, background illustration,
and the nested framing arrangements .
. to stay quick, a text-version is loaded first,
followed by the full graphics .
. after ending adde's menu-editing mode,
only the user's versions are shown .

. in the original keymap, app`authors can show
what they think the most popular functions are
by placing them on the easiest-reached keys .[5.6:
. user's can also have a library of keymaps,
including author's map, current map,
and any other user-designed maps .]

. the style of interaction between {user, keymap}
is user-selectable:
# remindful interaction style:
. when users are in command mode (vs text insert)
typing any key brings the keymap into view,
shows you what you just did, and waits for enter .
# compact interaction style:
. hitting a key fills the command box
with the name of the function you just selected,
and then the command box is waiting for
either {esc, enter} to {stop,launch} the command). [5.6:
. hitting enter on an empty command
would show the keymap .]
]-5.4
. users may want both a menusystem
and a keymap --(before now,
I thought a keymap would be sufficient).
. the keymap title bar has a list of
the types of objects in the current selection; [5.8:
but in the menubar this may be relegated to
a submenu of menu#edit .]

. users may want to place the app`menubar
either in the display`menubar,
or in the current window's menubar .[5.6:
. this will be possible on any system;
because, addx is acting as
a system within a system:
ie, it looks like it's being run by a vm player:
each window into addx represents an addx desktop
within which there are windows into adde documents .
summary of the window nesting:
. mac display ->
mac windows for a mac app named addx ->
addx windows for addx app named adde ->
app windows within an adde document .]

[5.4: hierarchical keymaps:

. the whole point of the keymap
is that it flattens the menu hierarchy
into a table of the user's choice;
however,
the existence of optional co.menus
implies the need for hierarchies of tables:
certain keys can be labeled to
launch new co.menus;
and then each optional co.menu item
is mapped to a cell of the co.menu-specific table .
. there could be room on the main table
in which case
optionality is expressed with grey-outs .
. the purpose of a keymap`title.bar
is indicate which table you selected;
left-arrow brings you to previous one .]

survey of programming architectures

11.15: web.adda/oop/architectures:

the categories of inheritance:

# type clustering (inclusion polymorphism):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10.23: news.adda/compositional modularity:
11.14: Bracha, Lindstrom 1992`Modularity meets Inheritance

We "unbundle" the roles of classes
by providing a suite of operators
independently controlling such effects as
combination, modification, encapsulation,
name resolution, and sharing,
all on the single notion of module.
All module operators are forms of inheritance.
Thus, inheritance not only is
not in conflict with modularity in our system,
but is its foundation.
This allows a previously unobtainable
spectrum of features
to be combined in a cohesive manner,
including multiple inheritance, mixins,
encapsulation and strong typing.
We demonstrate our approach in a language:
Jigsaw is modular in two senses:
# it manipulates modules,
# it is highly modular in its own conception,
permitting various module combinators to be
included, omitted, or newly constructed
in various realizations .

10.23: Banavar 1995`compositional modularity app framework:
11.14:

. it provides not only decomposition and encapsulation
but also module recomposition .
. the model of compositional modularity is itself
realized as a generic, reusable software arch',
an oo-app framework" Etyma
that borrows meta module operators
from the module manipulation lang, Jigsaw
-- Bracha 1992`modularity meets inheritance .

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

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

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

Bracha 2010`Modules as Objects in Newspeak:

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

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

Newspeak handles foreign functions
by wrapping them in an alien obj,
rather than let safe code
call unsafe functions directly .

--. this is the equivalent of SOA:
whatever you foreigners want to do,
do it on your own box (thread, module)
and send me the neat results .

optional ducktyping

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

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

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

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

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

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

oop with frameworks

10.23: adda/oop/the 3 layers:

. Padlipsky, author of
The Elements of Networking Style:
"(If you know what you're doing,
three layers is enough...)

. oop'ing needs only 3 layers,
not endless inheritance ?
that reminds how I saw oop as simply
a layer under structured programming: [11.14:
the 1980's structured paradigm meant that
programs could create vocabularies with functions;
but they could create class types
like the native types that were provide
where there was the use of binary ideograms
and implicit coercions among related types .
. the types were provided,
then you built your vocabulary of functions
on top of those types .]
. at that time,
I had not yet thought about frameworks ...

. one place where many levels of
inheritance can be appreciated,
is within the system it was modeled after:
biological classifications of animals
involving inherited features or behaviors .

. I would say the 3rd layer of Padlipsky's oop
is the type cluster, just as type Number is
for the numeric subtypes {R,Q,N,Z,C};
notice the Number type.class is not abstract;
it has the code that handles binary operations, [11.14:
and diff's in operand subtype;
eg, you don't coerce an int to rational
if the rational's value happens to be integral .]
. objects can interact with each other based on
having context menu's which include
recognized submenu's .
. this is programming to interfaces,
and doesn't involve the impl'inheritance
that is usually associcated with oop .

. in summary, the 3 layers of oop are:
#1: a type having an interface to share;
#2: a type claiming to adopt a shared interface;
#3: an app that instantiates interface adopters .

. frameworks are a sort of
structured programming with generics;
you can think of generics as a
layer under stuctured code,
parallel with type.classes .
[11.14:
. a structure library
gives you a language of functions
which you may compose in various ways;
ie, the library is an employee,
and you're the exec .
. a framework library takes the exec' seat
letting you customize its decisions
with your own structure library .
. a datatype is like a structure library
but it's purpose is to control modifications
to the obj's it will create .]