the standardized subtype.tag

12.8: adda/oop/the standardized subtype.tag:
27: summary:
. the most important feature of object orientation
is the support of polymorphism,
such that a "supertype" can declare variant formats
known as "subtypes" and know the current variant
by the value of a subtype.tag .
. if a type mgt supports subtyping,
then it also supports an object format
that puts the subtype.tag in a standard location,
so that it can be co-managed
by both the type mgt and the system run-time .
. subtypes codify not only the format variant
but also whether the object is constant,
and whether it is a value vs pointer vs function .

8.639: doing without:
. if there were no standardized subtype.tag
providing a bit for is-a-constant-subtype
then an alternative design is:
. when the system fills a parameter with a subtype.tag
the system knows
how the type's subtype.tags are encoded;
plus, all the type mgr's know
that when that system-provided tag
is not zero,
then that means there are
1 to 3 special messages from system:
# the subtype is not to be changed,
# the value is constant,
# the value is a ptr to function .

8.718: doing without/complicating:
. making room for a 2nd system-provided subtype.tag
seems to create a complication;
it seems much easier to simply ask all type mgt
to expect their subtype.tag
to be in a certain location on the object
and to expect a bit or the negative flag
to be used for indicating whether the object
is subtype-constrained
which means the subtype.tag is constant
(in our simplified oop model).

8.608: mis: is-constant via a pointer:
. just as universally recognized types
could include ptr to constant,
there could be a ptr to function instead of value .
9.334:
. the only place where a function could
stand in for a place expecting a value
is when the function was parameterless,
ie, all the parameters were implicit .
9.412: revision:
. instead of needing a pointer to an object
in order to say the object was constant
the is-constant bit could be in the subtype.tag .
. what if the type didn't have a subtype?
all types have at least one subtype
-- the constant vs variable subtypes
are universally shared by all types !
25.1013: well, ...:
. what about task types?
a process can't possibly be constant;
and, generally, my type may have
only private impl' variants;
and, won't have any public subtyping .
. anyway, if the type does declare subtyping,
it should make room for is-constant too .

9.352: the is-a-function subtype:
. in contrast to the is-constant bit,
the is-function difference wouldn't require
an entire bit of the subtype.tag;
it would just be one of the subtypes,
so if all the subtype.tags were
standardized to be a byte in size,
and if there was one bit for
[is a constant value],
and another bit for [is a constant subtype],
then there are 2^6 values for various subtypes
and one of those 2^6 subtypes could be
[this is not the value, it is access to
a parameterless function returning the value].
9.430:
. if a type wanted to support
function and pointer subtypes
its supertype's size would need to be
the size of a pointer, which is a lot of space
for something like truth.type
whose typical value only takes up a bit .

9.409: is-a-pointer subtype:
. there could also be a subtype saying
[value and subtype provided by pointer].

8: adda/oop/how to work with implicit type.tags:

. if a call had all operands in the same subtype,
then the compiler could call that subtype's operator,
and it wouldn't expect subtype.tags .
. if the call had mixed subtypes to operate on,
and any of the operands didn't have a subtype.tag
because they were implied by type constraint,
then the compiler would have to provide them
in the call to the supertype mgt .

628: todo:[done] actuals vs formals:
. mixing the idea of top-down stacking
with that of implicit type.tags,
is there any problem with
actual vs formal parameter types?
653:
. when function calls are nested,
we stack the root call down first,
so that its parameter's obj's are in place
to accept the returns from the nested calls .
. formal parameter's types are of concern only to
the compiler that is checking compatibility
between the formal and actual parameters .
. if the formal's type is already constrained
then it already matches the actual's subtype;
but if the type is generic, ie, an umbrella type
expecting a variety of subtypes,
and since the actual param
that is constrained to a particular subtype
will not have a type.tag
and this will fail the expectations of
the type mgt of a generic or supertype,
all actual parameters for supertyped formals
need a system-provided subtype.tag .