task.type's syntax and semantics

adda/co:
8.16: syntax:
. when an object is given a message,
it is the object's type mgt that applies a method;
and, these type mgr's are tasks (co.programs);
but how do we get the obj's themselves
to be tasks? (ie, running code on a separate thread).
. we can use the same syntax as for interfaces,
but prefixed with the keyword"(co):
myTaskType.type: co < list your interface >;
myTaskObj.co(anInterfaceTypemark); --[11.11:
since co is a type with a type.type parameter,
we can use this syntax:
myTaskObj.co.anInterfaceTypemark .]

8.21: ideas for co.programming semantics:

11.15: review of how types work:
. when a var is declared,
this actually involves the instantiation of 2 objects:
. first, if not already instantiated,
the type mgt needs itself running as a co.program;
then the type mgt can instantiate the declared var .
. let's call this the object server idea;
the other idea is the subprogram template:
. subprogram calls instantiate the subprogram's template,
so that most of the subprogram's object, the constant part,
can be shared among the many calls, the instantiations .
. we could have tasks that work either way:
a task type could work like a subprogram template,
or like a type mgt's object server, itself a co.program,
instantiating other co.programs,
and able to share class vars with them .

. coprograms can use interfaces defs that are
just like those used for defining types,
including the allowance of class vars .
. the task.type's mgt is always there to
coordinate both the instantiations of its members,
and their communications via class vars .

typedef's can be non-globals:
. type mgt's obj's should be at the level of their visibility;
eg, since number.type is known globally,
it's task should be spawned by the system
and then shared by all client subprograms;
likewise, if a type is defined local to a subprogram, Sub,
then the type mgt's co.program object
is local to Sub's subheap .
11.15:
. when consider type compatability,
one must consider the type's full path;
eg, if Number is redefined locally,
then that Number is not compatable with the
system-wide Number typedef .

11.11: adda/co/promise/syntax as pro(type).type:
. if the task.type is defined in terms of an interface,
that doesn't allow for the distinction between
calls that are asynchronous vs blocking;
so, how can we extend interface types for asynch?
. "(pro-) has a related double meaning:
it is part of the word "(promise),
and "(pro-x) means working toward obtaining x .
. if the out.mode param is type: .pro.t,
then it returns asynchronously:
meaning that when the promise has been kept,
the server signals the caller that email is waiting;
and then the caller knows to check the email
where there are details about what promise has been kept
or what is ready to access .