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?

Hugh Darwen

On Jun 12, 4:31*am, David BL <davi... (AT) iinet (DOT) net.au> wrote:

I'm sure the "opposite effect" you refer to is not his intention. The
point really is that the semantics of an update operator are clearly
defined in terms of assignment--like INSERT(RV,r) might be defined as
equivalent to RV := RV UNION r. This is indeed "not very
illuminating" but it gives us the convenience of using the term
"multiple assignment" to refer to a single statement that
simultaneously updates one or more variables, and to define the
semantics, as we do in TTM, in terms of assignment. It also gives us
a reasonably snappy name for the principle we call The Assignment
Principle (stating that immediately following the assignment of v to
V, the expression v = V shall evaluate to TRUE). The Assignment
Principle is worth enunciating both SQL sometimes violates it
(updating views WITHOUT CHECK OPTION!).

In fact, Date's most recent proposals for updating relational views
(with which, as it happens, I do not fully agree) are expressed in
terms of the traditional database update operators, INSERT, DELETE,
and UPDATE (the last being defined as a shorthand for simultaneous
INSERT and DELETE). Moreover, we propose that in addition to the
selectors and THE_ operators implied by possreps, certain special
update operators are also implied.

Hugh Darwen

On Jun 17, 8:15 pm, Hugh Darwen <hughdar... (AT) gmail (DOT) com> wrote:
Indeed, that's an excellent description.

On Jun 17, 8:15 pm, Hugh Darwen <hughdar... (AT) gmail (DOT) com> wrote:

[snip]

Towards that aim, I rather like the idea of extending the syntax of my
proposed DDL slightly by allowing for bidirectional arrow symbols on
the operator signature declarations. This is to declare the fact that
the operator is bijective (a "selector"). This is on the domain which
is the cartesian product on the declared types of the arguments, or a
restricted comprehension on the same, (designated with a boolean
expression over the names of the arguments coming after the keyword
'on'). For example:

type Rational;

Rational <-->
rational(
Integer numerator,
Integer denominator)
on denominator > 0 and
coprime(numerator,denominator);

This selector declaration implicitly declares the component-wise
operators on its inverse:

Integer <--- numerator(Rational);
Integer <--- denominator(Rational);

There are some close similarities to Tutorial D, but some useful
syntactic differences (e.g. subtype declarations are orthogonal, and
it is easy to see how additional selectors can be independently
declared on pre-existing or third party types).

The following is the definition of literal given in TTM:

"A literal is an expression denoting a selector
operator invocation (see RM Prescriptions 4, 9,
and 10) in which every argument expression is a
literal in turn."

Elsewhere, TTM refers to the fact that a literal denotes a value, and
this is the usual terminology for a formal semantics. I'm not
certain, but my impression is that the word 'denoting' in the above
definition of literal actually relates to providing latitude to the
language (i.e. consistent with Hugh saying "TTM is not at all
concerned with syntax"). It is permissible for a literal expression
to use operators that are not selectors, but only to the extent that
there is a defined sense in which that expression is regarded as a
convenient alternative syntax of an expression only using selectors.

For the time being I'll restrict myself to operators that are
selectors. I want to investigate what it means to employ nullary
operators like 0 (not to be confused with the number which it
denotes). Can a nullary operator be a selector? Indeed it can, but
only if both the domain and codomain are the empty set. What is
needed is a subtype of Natural, with the subtype-by-constraint
condition equal to 'false'. Let's call this empty subtype
EmptyNatural. This suggests the following:
Counting isa Natural;
EmptyNatural isa Natural;

EmptyNatural <--> 0;
Counting <--> successor(Natural predecessor);

In general the inverse of a unary selector operator without an 'on'
constraint is also a unary selector operator without an 'on'
constraint. Therefore it is assumed the following selector is
implicitly declared:

Natural <--> predecessor(Counting successor);

So, in a slightly tricky fashion, we have managed to meet the
requirement that each type has at least one selector as per TTM.

Given that there is a defined sense in which nullary operators can be
regarded as selectors, it would now be appropriate to relax that
restriction on all nullary operators. So the end result is simply:

Counting isa Natural;
Natural <--- 0;
Counting <--> successor(Natural predecessor);