anonymous and literal adt's

3.19: adda/oop/anonymous types:
. abstract typing means a symbol's useage
is declared in terms of operations;
eg,

( num.type: <+, -,  /, *>;
, x.num .
)

. that example could instead be
written with an anonymous type as:

x.<+, -,  /, *>

. despite that being harder to read,
a benefit is that a simpler syntax
with fewer exceptions;
the alternative is disallowing all type literals;
ie, having to name all types !

3.19: todo.adda/oop/abstract literals:
. adda still needs a way to express
literal abstract types symbolically
rather than as a list of operator literals .
... that gets back to question of
how to express a union of types:
ie, I'm not listing the available operations
I'm listing the names of types
that will list available operations .

3.21: adda/oop/abstract type literals:
. how is adda allowing new types in terms of old
without assuming the old and new are
assignment compatable ?
eg, does it impl' type color with number
yet still warn of type mismatch when
number is used as a color?
--. actually,
that wouldn't be a good example since
the system should support physics' way of
typing numeric obj's with dimensions;
ie, (x color) returns a color defined by
the numeric value of x .

. adda still needs a way to say
a type's interface is the same as a given type
but also say they are not compatable types;
eg,
my.type: another.type`face;
--. here,
a type's face returns an interface literal;
eg,
the literal face of numbers is

<+,-,/,*, abs(), sign(), ...> .

. to merge many faces, use union:
(face u face ...)
--. if a face is a set
are you calling the face literal a set notation ?
a set is any unordered list in which
duplicates can be tossed .

review of aggregate-type`literals:

record var with anonymous type: rec.(v.t, ..)
record type: (v.t, ...)
array var with anonymous type: array#(v.t, ..).t
array type: #(v.t, ...).t .
-- array type literals can also symbolic:
#enum-range-symbol.t,
or enum range literal:
#{e1, e2, ...}.t .

. notice functions are sets {,,,}
but arrays are structs (,,,)
according to the design of their literals;
there were 2 issues to juggle:
have all struct's literals indicate type uniquely,
but also keep things making sense without special rules .

. for types' literals
the combination of enclosure and content syntax
are what identify which type they are:

enum: {symbol, ..}
record: (v.t, ...)
function: (x).t
adt: < symbol, ...>

. in the adt,
symbols are assumed to be any number of args
unless the arg is specified;
an operator listed without a parenthetical
means 1,2, or more args, with infix accepted .
. abs() means one or more args
but as prefix only, not infix .

. for functions with multiple param's
of various types: f(x.T1, y.T2, ...)
when an param's type is not given
that means its the same type as
the adt's name;

eg, G: < f(x, y.t), ...>

-- x is type G like so: f(x.G, y.t) .
. if num.type has this function:
image().#.char
it means:
image(x.num).#.char .