Re: An alternative to possreps

On Jun 11, 10:04 pm, Erwin <e.sm..._at_myonline.be> wrote:
> On 9 jun, 08:28, David BL <davi..._at_iinet.net.au> wrote:
>
>
>
> > I agree that update operators are an important consideration.
>
> > Nevertheless I don't think type systems per se should have anything to
> > do with specifying what update operators are available on variables.
>
> Note that TTM doesn't do any such thing. D&D are quite explicit in
> stating that in fact there is only one update operator : assignment.

It's clear that every update to a variable can be regarded as logically equivalent to some assignment to that variable. However I fail to see how this observation is very illuminating. Indeed it seems to have the opposite effect by suggesting there is only one kind of update so don't waste your time studying the very rich and interesting area of specialised update operators.

In a system using Operational Transformation, update operations are not generally characterised as assignments. The update operations are regarded as functions which map before values to after values on the target variable. These functions can be modelled according to the semantics of the associated update operator, and this leads to the idea of types of update operations, with possible physical or logical representations that depend on the type of update. Update operations can be serialised as values very efficiently between computers and transformed and applied in different orders at different sites so as to synchronise replicated data without distributed locks or distributed transactions. It is a very remarkable and impressive approach to multi-user editing of data, since users experience zero latency for local edits, and it also allows for long lived isolation between users making complex changes where they don't want to see each other's partially completed work.

Date's Introduction book provides an example of the REFLECT operator:

OPERATOR REFLECT (P POINT) UPDATES P;
  BEGIN;
    THE_X(P) := -THE_X(P);
    THE_Y(P) := -THE_Y(P);
    RETURN;
  END;
END OPERATOR; In that text this is explicitly referred to as an update operator. I find it arbitrary to claim that this update operator is "really an assignment operator". In a way that assumes that update operations are not themselves the subject of modelling, and I find that to be a narrow point of view.

> > I consider a type to be a set of values plus operators on *values* (or
> > what Date calls read-only operators).
>
> In TTM, a type is just a set of values. Nothing more. No operators
> involved (in the type being what it is, namely just a set of values,
> that is).

Page 606 of my copy of Date's Introduction book states:

"Let us begin, therefore, by defining the term carefully: A *type* is a /named set of values/ (i.e., all possible values of the type in question), along with an associated set of /operators/ that can be applied to values and variables of the type in question."

It is also stated on that page "those operators include ... an assignment operator ..." (so evidently Date considers a type to include both read-only and update operators).

> The fact that some operators are also needed to be able to make
> productive use of a type, does not mean that a type "per se" "becomes
> something more" than just precisely this set of values !

It is a matter of definition. I prefer to consider a type to be a set of values plus the applicable read-only operators.

> Nor does a type become "something more than just a set of values" as a
> consequence of the fact that some of those needed operators (e.g.,
> value selectors) are so "tightly intertwined" with the type per se,
> that it becomes useful to introduce a single syntactic construct which
> declares/defines both the type itself and those related operators.
> Such syntactic construct are a matter of practicality toward the
> language user.

> > Update operators can be modelled at the logical level of discourse
> > using a language allowing variables to be passed by reference in some
> > sense. E.g.
>
> > setmagnitude(Complex& c, Real m)
> > {
> > c := polar(m,phase(c));
> > }
>
> If the c argument is a reference, then your assignment to this
> reference is invalid.
>
> No pointers, no pass-by-reference, no variables containing
> variables, ... in TTM.

With regard to pass-by-reference I read your statement as saying TTM doesn't use this terminology, instead it uses different terminology for the logically equivalent thing.

OPERATOR SETMAGNITUDE(C COMPLEX, M REAL) UPDATES C;   BEGIN;
    THE_MAGNITUDE(C) := M;
    RETURN;
  END;
END OPERATOR;
> The TTM way is :
>
> TYPE COMPLEX (IMAG REAL, REAL REAL);
> VAR COMPLEX MYVAR=COMPLEX(0.0, 0.0);
> THE_IMAG(MYVAR) := new imag value;

It also allows for the 'UPDATES' keyword, which allows for userdefined  operators that update a variable.

> This latter line is syntactic shorthand for the assignment
>
> MYVAR := COMPLEX(new imag value, THE_REAL(MYVAR));
>
> With all that that might entail in case where the variable is a huge
> program-local relation variable ...

Such a relation variable could itself be regarded as a "pseudovariable" (and the database variable is the "real one"). I don't like this terminology since it suggests a pseudovariable isn't really a variable (it only pretends) even though it satisfies all the characteristics of a variable given by D&D.

I would prefer D&D to use a term that indicates whether or not the value of one variable is uniquely and implicitly determined by the value of another. E.g. say that variable v1 is /derived/ from variable v2. Note that a variable is only said to be derived in relative terms (i.e. with respect to some other variable).

> But note that there is no such thing as a "setter" operator "inside"
> the type, so to speak.

That contradicts page 606 of Date's Introduction book. Received on Sun Jun 12 2011 - 05:31:09 CEST