generic type vs container type

1.4: adda/type/{generic, container}-type def's:
. there is a syntax for parametric types generally,
with multiple params that include
both types and non-types ? yes:
[1.6:
. the parameterized type is a sort of generic;
so, there are 2 points at which it is instantiated:
once to define the concrete type,
and then again for each use of that concrete type
in defining an obj' instance .
. to distinguish these,
use the terms {generic, container}-type .
. the {array, pointer} are really containers;
on the way to defining more container types,
you can use a generic type
which then must be instantiated
before use by container obj's .
. a container type could accept a record type as its leaf;
then each of those record fields
could be instantiations of a generic-type
that could return a container-type .
. the generic-types should not need
separate instantiation:
[1.7: eg,
( myLeafType.type: gentype(init)
; x.myLeafType; )
can also be done as x.gentype(init) .]
. here's a combination of generic and container instantiations
in one term:
pointertype(inits for variant selection).myLeafType .

. arrays, pointers, and functions are container types;
how are new container types defined ?
. recall that pointers and arrays are
types of functions [expressing container types]
but, can new [container] types be
defined like functions without confusion ?
yes:
. a function where the arg is of type .type;
eg, pointer.type is defined as:
/(type).type;
this works with these rules:
(1) function args are not required to be paren'd,
(2) types are preceded by a dot:
/.txt = /(.txt).

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 .

typedef syntax vs terminology trade-offs

3.25: adda/oop/classes vs types:

. if using 2 keywords for defining class vs type,
the class could mean a type that is an
adt (abstract data type),
so then one could replace the type`def's
angle brackets (used for an interface literal)
with a simple enclosure
since a class`def would always be an interface,
and would therefore no longer need a variety
of enclosures; eg, t.class: (,,,) .
3.30: adda/dstr/nominally typed structs:
. another way to avoid various enclosure types,
is to use typing of parentheses:
(.braces ,,,), (.set ,,,) .

. any reason to reserve the terms"{class, classwide}
for the way ada uses the concept of class-wide ?
[3.31: adda uses class-wide semantics universally ]
. notice the english meanings of
"(what type) vs "(what class),
or "(typical) vs "(classical) .
...
. a good reserved meaning for "(class) vs "(type),
is when dealing with generics,
eg, the class of scalars
includes many enum.types .
3.27:
. generally, the meaning of "(class) within the
field of logic -- the origins of oop nomenclature --
is a set defined by a predicate .
. a class can include many types,
and for many reasons .
. the type.classes of interest to oop and generics
are those where membership is defined by
shared interfaces .

degrees of freedom in function typing

3.20: adda/oop/degrees of freedom in function typing:

. a valuable freedom of expression I first saw in Python
is what might be called the anonymous protocols .

. is there some way to minimize syntax declarations?
the most general form is something like
{-, /}
where it can be either unary or binary,
and you know when it's binary because
either it will have an infix position
or it will be a prefix to a binary list .
. then the way you could sort out ambiguities
is to leave it up to the implementation
to be precise about
what arg arrangements it expects .
. just as in lisp,
every syntax in {uniop, biop, multiop}
can be reduced to a single arg
that is a list of various sizes .
. the default function signature is for an operation
(ie, a function where all param's have the same supertype)
then every operation is expected to support
a list of any size .
. this would work for num.type
if /x would mean 1/x
just as -x means 0-x;
and, if any list was greater than 2 args,
it could be recursively evaluated as a
list of binary operations .

. the oop paradigm I've had in mind
has assumed there's some efficiency
in the convention that
supertypes were declared by name,
so that then param's could be typed by name,
and finally there were 2 ways to find
matching function calls:
(1) eg, int+real:
. the operands will all have the same supertype,
so the compiler can search that supertype
for a matching operator .
(2) lib`fn(num); ... fn(int):
. the function may be in a nearby library,
and the call's arg will be compatible with
the function's declared arg .

. but does that work as a contract?
if I'm not mentioning the arg length,
then can't the caller and server
disagree on that ?
. isn't there generally a problem with
parameters sometimes being misplaced?
and don't we solve that by declaring our
parameter structures?
. there should be language for
both cases:
when needing the freedom of genericity,
and when needing help with conforming to
efficient, picky param' formats .

syntax for picky functions in an adt:
. say arg x needs to support an operation f,
where x is not just any place in f's arg list,
but is the 2nd arg,
and the 1st arg is of t.type .

eg, x.< f(first.t, x) > .

3.22: web.adda/cs/generics:
. generic programming is defined as when
all obj's are typed exclusively with
abstract data types .

generics

adda/generics:

2.2:
. what does ada's generic look like as c code?
it's typically a function call that returns a subprogram:
. subGenericInstance`= genericSub(instantiation param's)
. it's setting parameters that will be used by
every subsequent call to subGenericInstance .
. when the generic's param is of type "(type),
that is translated using the fact that
types can be expressed as a collection of pointers to
the operations that impl' that type .
eg, if there exists genericSub(number.type)
then the actual param can be any type that
supports the bi'ops {+, -, *, /}
and the uni'ops {-, /} .
caveat:
. ada generics, due to efficiency concerns,
likely involve some additional semantics .

2.4: translation to c:
. generics can be instantiated numerous times;
each instantiation means setting up a record
containing pointers to generic's instantiation arg's,
and then passing that record with each call to genericInstanceSub(x) .
. say the record would be called [generic instantiation#n's arg's],
then each call would be:
genericInstanceSub([generic instantiation#n's arg's], x) .

2.6:
. if the generic is a package instead of a sub',
then it practically means
the package includes both its own components
plus its generic instantiation record .

2.6:
. a generic instantiation is considered to be first-class,
when it can be treated like any other subprogram;
for this to occur,
a sub', which is usually represented by a pointer,
must include along with that pointer,
a tag indicating whether it's nested,
and whether it's generic
(each means 1bit of the tag) .
--. if c has some restrictions about function typing,
then all dynamic functions can be impl'd as
unary or binary operations over etree .

2.4:
. one of the struct's fields is a pointer to a callable generic .
. this is not really needed because it's statically known
but part of supporting reflection is that
instead of there being just function pointers,
there is an id bundled with the pointer
so that the program has access to the name of a function
along with details known statically about the function
like its signature (req'd param`types, and provided output`types) .
. along with a function'id is the environ.ptr,
for cases where the function is declared nested .
. the generics.ptr
-- for cases where the function is generic --
is pointing at the generic's instantiation record .

how does adda define a generic?
they are functions returning some cstr,
typically a function .
their param's can include types (sets of function ptrs) .
eg,
G(T).(X).Y; -- G is a generic returning a sub' of type (X).Y
f(x).y: G(t) . -- f is a constant function
defined as an instantiation of G .
neat.type: (x).y; -- "(neat) is a constant type name for (x).y .
G(T).neat; -- G returns a function of type neat .
f.neat: G(t) -- f is a constant function
defined as an instantiation of G .

. to become familiar with subtleties of generics,
need to see examples of them in c++ and ada .

generics

1.22: adda/generics:
. generics are actually functions;
ie, the syntax is
f(what makes it generic).[what's instantiated]
eg, given the declaration f(type).pkg
the function return for f(x)
is a usable pkg .
[1.30:
f().().y is a generic function . ]

generics

10.7: adda/tracking a type's operations for generics:

. how is a sub' generic?

the type is infered by

the operations used by an untyped arg [.?]

[?.] ptr's to the arg's methods for these operations

become implicit param's of the subroutine .

. so that's a needed property:

given an object and a function name,

get a ptr to obj's method for that function .

. how to include multiop's?

eg, cvt2str(x.tall, y.string)?

an arg is given an obj,

and every obj has a particular type at any given time,

that type must have collected a dbase of

every aux'function whose signature includes that type .

[10.10:

or the system needs to keep a dbase of operations

where methods can be found dynamically . ]