Re: no names allowed, we serve types only

From: David BL <davidbl_at_iinet.net.au>
Date: Sun, 21 Feb 2010 18:40:36 -0800 (PST)
Message-ID: <9e70ff30-c2ee-4a17-8e00-a0d3f3043494_at_k5g2000pra.googlegroups.com>



On Feb 21, 7:05 pm, Jan Hidders <hidd..._at_gmail.com> wrote:
> On 20 feb, 03:40, David BL <davi..._at_iinet.net.au> wrote:
>
> > I agree this provides some motivation, but it doesn't seem sufficient
> > justification to "conflate" concerns (as Bob says). The crucial point
> > is this: The attribute domains are part of the relation-type, whereas
> > the attribute names are part of the relation-value. What happens with
> > your suggestion?

I got that wrong. I should have said:

The crucial point is this: Whereas both the declared attribute names and attribute domains are part of the relation-type, only the attribute names are part of the relation-value.

> > It's very important to keep a clear separation between a value and its
> > declared type, in order to understand equality. Your suggestion ends
> > up conflating relation-type and relation-value.
>
> > How do you support sub-typing of relation-types according to sub-
> > typing of the attribute domains, and still allow for addressing the
> > attributes by type name?
>
> That's actually no problem at all. The formal definition of a relation
> type / relation header in Keith's approach would be a set of types
> (*). For those types you can define a subtyping relation as follows: a
> relation header H1 is said to be a subtype of H2 if for every type in
> R2 there is a subtype in R1. It's even possible to have a matching
> semantics with that that follows the subtype=subset principle. So no
> notion of coercion is really needed here.
>
> (*) Note there would / should be an additional requirement that a
> header can only contain incomparable types, i.e., it cannot contain t1
> and t2 such that t1 is a proper subtype of t2.

There is a problem.

Let's write t1 <= t2 if t1 is a subtype of t2 (let this include the case t1 = t2).

Definition: header H is valid if for all t1,t2 in H,

  t1 <= t2 implies t1 = t2.

(this is your "additional requirement")

Definition: H1 <= H2 if
  exists bijection f from H1 to H2
    such that for each t in H1, t <= f(t).

Unfortunately even assuming H1,H2 are valid doesn't imply that a bijection is unique (if it exists).

Here is a counter example: H1 = {t1,t2}, H2 = {t3,t4} where t1,t2,t3,t4 are all distinct types where:

  not  t1 <= t2
  not  t2 <= t1
  not  t3 <= t4
  not  t4 <= t3
  t1 <= t3
  t1 <= t4

  t2 <= t3
  t2 <= t4

In this example, H1, H2 are both valid and there are two distinct bijections available. Ambiguity in the bijection is incompatible with the subtype = subset principle. So multiple inheritance throws a spanner in the works. The only way to salvage the situation is to require the bijection be unique (so in the above example it is deemed that H1 is not a subtype of H2). However I find this gratuitous at best. Received on Sun Feb 21 2010 - 20:40:36 CST

Original text of this message