Re: relations aren't types?
Date: Fri, 26 Dec 2003 17:23:42 GMT
"Bob Badour" <bbadour_at_golden.net> wrote in message news:1NCdnXt3dKvOR3qi4p2dnA_at_golden.net...
> "Marshall Spight" <mspight_at_dnai.com> wrote in message
> > > >
> > > > I have to agree. I don't see any logical difference between a row
> > > > in a relation and an object. (Alternatively, between a relation
> > > > heading type and a class.)
> > >
> > > One has transparent structure and generic operations while the other has
> > > opaque structure and specific operations. You really see no logical
> > > difference? The differences glare at me.
> > I see no *logical* difference between transparent structure and opaque
> > structure. That's an implementation detail.
> We are talking about logical structure in tuples and relations not physical
> structure so the transparency or opacity is a logical feature.
My thinking on this issue has changed a bit. Now it strikes me that the important question is: what is an atomic type? It does not make sense to have a unary relation over an unnamed atomic type. But considering a unary relation over a non-atomic type to be logically identical to an n-ary relation over the named subcomponents of the type strikes me as quite a valuable idea. The fact that the subcomponents already have names makes it easy.
It is clear that system-defined types like int, char, and float
are atomic. What's not so clear is whether user-defined types
will be atomic. TTM seems to assume that they will be; I
claim it is better if they aren't.
Put another way: I don't see the value to user-defined opaque
types. Clearly the system has to have a few opaque types:
int, float, relation are necessarily opaque. But if one is
interested in data management, then one should not have
opacity: you can't manage what you can't see. Because of
this, I propose that all user-defined types *must* be transparent
and not opaque. If that's so, then it makes sense to consider
Put another way: I don't see the value to user-defined opaque types. Clearly the system has to have a few opaque types: int, float, relation are necessarily opaque. But if one is interested in data management, then one should not have opacity: you can't manage what you can't see. Because of this, I propose that all user-defined types *must* be transparent and not opaque. If that's so, then it makes sense to considera relation as a generic type that can be parameterized with a *single* user defined type, which specifies the named attributes of the relation.
> Keep in mind that each tuple and each relation does have a type, and one can
> have tuple-valued and relation-valued attributes. The key question is
> whether one can have generic tuple-valued or generic relation-valued
> attributes. I suggest the principle of cautious design should deter us from
> pursuing generic attributes until we know more about the effects of allowing
I'm less cautious. It strikes me that languages with support for generic programming have had substantial success, and I see no reason to believe their success won't transfer to a relation-centered language.
> > Simple example: a Point relation with int x, int y columns vs.
> > a unary relation on a tuple-type with attributes int x, int y.
> > What's the logical difference?
> One has a single attribute (for which you forgot to specify the name) with a
> tuple type and the other has two numeric attributes. One can convert either
> one into the other, but this requires an additional operation.
I say: why bother with the conversion? Why not just declare the two cases as identical? I don't see any advantage to distinguishing between the two cases. (Maybe there is an implementation advantage.)
Marshall Received on Fri Dec 26 2003 - 18:23:42 CET