Re: relations aren't types?

"Bob Badour" <bbadour_at_golden.net> wrote in message news:1NCdnXt3dKvOR3qi4p2dnA_at_golden.net...
> "Marshall Spight" <mspight_at_dnai.com> wrote in message
> news:FXFFb.177009$_M.808167_at_attbi_s54...
> > > >
> > > > 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.

>

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 a relation as a generic type that can be parameterized with a *single* user defined type, which specifies the named attributes of the relation.

If I'm missing something, please let me know. An example of some negative consequence (such as a contradiction or an ambiguity) would be helpful.

> 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
> them.

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?

>

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