David BL and I have been exchanging emails privately in the past few
days and we have reached a common understanding and agreement. I hope
the following expresses that agreement.
TTM is not at all concerned with syntax. It uses the terms "selector"
and "possrep" to define concepts on which to base the semantics of
certain operators that it proposes to be required in connection with
every type. A selector for type T is a bijective function (assuming a
canonical form for its domain), mapping possrep values to values of
type T and vice versa. It is the inverse mapping that allows our
"THE_" operators to be defined for each possrep component.
The motivation for requiring such operators is (a) to guarantee that
every value can be denoted by a literal (an expression in which no
variables are referenced), and (b) to guarantee that sufficient
primitive operators are available for the defining of any further
operators that users of T might require.
An assessment of TTM and our IM could question our motivation: are
those guarantees really necessary? If the answer is "yes", then it
could go on to question whether TTM really does meet them, with or
without the IM.
David doesn't disagree with our motivation. Moreover, his proposal is
concerned with syntax rather than semantics and his aim is a laudable
one: proper separation of concerns. In Tutorial D, our syntax for
user-defined scalar types uses explicit POSSREP declarations from
which the required operators are automatically generated by the system
(you can try them out with Dave Voorhis's Rel, an implementation of
Tutorial D). Well, Tutorial D was expressly designed to illustrate
our proposals, so that was an obvious approach to take. In David's
proposal, a type is defined by a bunch of operator signatures under an
assumption that the semantics for these operators are defined
elsewhere. If those semantics can be shown to address my points (a)
and (b), then such a type conforms to TTM; otherwise, it doesn't.
Thus, I would agree that David's proposal is a possible replacement
for Tutorial D's way of defining scalar types, but it doesn't yet do
the job of guaranteeing those required semantics.
Okay, David?