Re: Questions on possreps

From: David BL <davidbl_at_iinet.net.au>
Date: Mon, 13 Jun 2011 10:01:24 -0700 (PDT)
Message-ID: <9e909783-8fbb-4c7a-9be0-5768b9d5ed27_at_v11g2000prk.googlegroups.com>


On Jun 13, 7:40 pm, Hugh Darwen <hughdar..._at_gmail.com> wrote:
> On May 26, 5:04 am, David BL <davi..._at_iinet.net.au> wrote:
>
> > On page 116 of An Introduction to Database Systems (8th edition) Chris
> > Date [...]
>
> David BL cites an example from that book and asks a lot of questions
> about possreps, sometimes using phrasing such as "Does Date think
> that ...", "Is it Date's position that ...".
>
> The possrep concept arose in a joint work by me and Chris Date: "The
> Third Manifesto", which Erwin Smout has correctly referred to in his
> responses, both in this thread and the earlier one on David BL's
> alternative proposal. I have not had time to study the entire
> discussions in detail but I know Erwin understands our work very well
> and I doubt whether I would disagree with any of his responses.

I agree that Erwin is very knowledgeable.

> David: I'm just wondering if you've actually been able to study The
> Third Manifesto, our proposed Inheritance Model, and the detailed
> rationales and discussions we have given in our books on this
> subject. The official versions of TTM and the IM are now in "Database
> Explorations" (Trafford, 2010) but "Databases, Types, and The
> Relational Model" (Addison-Wesley, 2007) is probably more useful
> because it contains the detailed discussions whereas the later book
> just explains why we made certain minor changes in the latest
> versions. If you haven't, you may find that those discussions give
> you answers to many of your questions. Also, my websitewww.thethirdmanifesto.com
> contains some material you might find useful, include the bare bones
> of TTM and the IM.

I have a copy of Date's Introduction book, but not the other books that are relevant. I've read a good deal of the online material referenced by the TTM web site, so for example I'm familiar with the RM prescriptions, your paper "Towards an Agreeable Model of Type Inheritance" and looked at the grammar of Tutorial D on occasion. However, I certainly don't have an in depth knowledge of the TTM, nor the "detailed rationale" that you speak of.

BTW I think the IM is very impressive.

> For now, I just hope the following points about possreps and selectors
> are clear:
>
> 1. A selector S for type T is an operator that has certain special
> properties that we regard as required--and I mean required in a well-
> designed computer language, and I realise that opinions as to what
> "well-designed" entails may differ. The special properties are, quite
> simply, (a) every invocation of S denotes a value of type T, and (b)
> for every value V of type T there is an invocation of S that denotes
> V.

I'll treat that as a very concise definition of the term "selector". As a point of clarification I note that (a) implies that a selector for type T cannot also be a selector for a proper subtype of T, and (b) implies that a selector for type T cannot also be a selector for a proper supertype of T.

> 2. A possrep declaration is a way of defining a signature for a
> selector, along with a constraint (just like your own proposed
> definition for numerical division, which includes a constraint to the
> effect that the divisor, a value of type real, must not be zero).
> (Btw, your idea of applying a constraint on the parameters of any
> operator is one that I don't think occurred to me and Date, and I find
> it interesting.)

Agreed. I also see a possrep as declaring a set of THE_ operators, and pseudovariables provide a convenient shorthand for specifying certain updates.

> 3. At least one selector must be available for every type, from which
> it follows that for every value V of every type there will be at least
> one selector invocation that denotes V.

I find this unreasonable when I consider union types such as PLANE_FIGURE, since it would be impractical for it to have an appropriate selector according to your definition (a selector for a subtype like CIRCLE is not deemed to be a selector for PLANE_FIGURE).

> 4. If a selector S is defined by a possrep declaration, then the
> parameters for S correspond to the components of the possrep. We
> assume that if two invocations of S differ in at least one argument,
> then those two invocations denote different values. Thus, if we take
> possrep CARTESIAN(X REAL, Y REAL) for type POINT, then the operators
> THE_X(P POINT) and THE_Y(P POINT) are well defined: every point has
> exactly one X value and exactly one Y value. We assume that the
> declaration of such a possrep guarantees that users of the type in
> question will be able to develop whatever operators they desire for
> that type. (So, yes, a canonical form is needed in cases like the
> numerator/denominator possrep for type RATIONAL. That could be
> addressed in the physical representation, such that
> THE_NUM(RATIONAL(2,4)) and THE_DEN((RATIONAL(2,4)) yield 1 and 2,
> respectively--a bit of a tall order! It could also be addressed by a
> constraint on the possrep.

I can understand that it's important for the THE_ operators to be well defined, so I agree with your approach. Another advantage is that the equality operator is implicitly defined.

I assume the downside is that the canonical form is imposed on the selectors. i.e. they may have constraints that make them harder to use, and this might be a source of surprise and annoyance for users, such as when a polar representation of a complex number fails because the phase wasn't in the canonical range.

> Some people have argued that selectors aren't always needed--in other
> words, they don't mind allowing a type to contain values that cannot
> be denoted by a single expression in the language. We admit that in
> practice nobody would want to invoke a selector to denote the entire
> content of the film "Gone with The Wind", a value of type Video, but
> we still think a well-designed language should make that a theoretical
> possibility. I don't think we could disagree with an alternative
> model that meets the same objectives as I have outlined above, nor
> would we necessarily disagree with one that fails to meet them but is
> perhaps intended for rather less general use, so long as its
> deficiencies and advantages are clear.

I agree that the aim should be that any value can be represented by a single expression in the language. Received on Mon Jun 13 2011 - 19:01:24 CEST

Original text of this message