Re: no names allowed, we serve types only

On Feb 14, 12:41 am, Ben Finney <bignose+hates-s..._at_benfinney.id.au> wrote:
> Keith H Duggar <dug..._at_alum.mit.edu> writes:
>
> > Of course the conventional definition of a relation's header is a set
> > of ordered pairs of "attributes" of the form <A, T> where A is the
> > "name" of the attribute (which must be unique within the header) and T
> > is a type.
>
> The use of “set of ordered pairs” is telling. Note that the *pairs* are
> ordered, while the *set* is not; the attributes are unordered within the
> header.

Dude, I think we all know what "set" and "ordered pair" means.

> > I'm wondering, do we really need A? Can we not simplify this header
> > notion to just a set of types?
>
> The point of a unique name is to be able to address the attribute.

And they are redundant if the types are unique.

> Without it, there would be no way to distinguish between attributes of
> identical types in the header.

Which is why I said you could "copy" identical types to yield unique but related types.

> There would also be no way to change the type of an attribute without
> also changing all the references to that attribute, even ones where the
> type is irrelevant.

Finally we arrive at some interesting and useful point. I have two points in response. First it is wrong that you cannot change the type without also referring to attribute references and least in many cases.
Take my point example:

      Point2D = {copy Integer X, copy Integer Y}

The attributes are referred to by the semantic types X and Y. So if I want to change the representation type I simply change the header declaration to say Real

      Point2D = {copy Real X, copy Real Y}

but that's it! Because all the other references are to X and Y not Integer.

Second, as I said in my original post

> > So aren't the "ordered pair" and "attribute names" a perhaps
> > sometimes convenient yet always unnecessary complication?

so while I agree they can "sometimes be convenient" I'm saying they are not necessary. Also I think we probably overestimate their convenience because we are used to dealing with systems that have painfully limited type systems (domain support) and IDE support.

For example your objection above implies that "changing all the references" is somehow difficult. That is not the case if you have a suitably powerful development environment. I change names and types often in my coding work yet it is rarely painful due to careful programming and a powerful development toolset.

> > So aren't the "ordered pair" and "attribute names" a perhaps sometimes
> > convenient yet always unnecessary complication? We can do all we need
> > to solely with types and sufficiently rich type systems.
>
> You think we don't need to uniquely address attributes within a header?

You think my proposal does not allow you to uniquely address header attributes? I think you need to try again, perhaps with less of a focus on "telling us" what sets and ordered pairs are.

KHD Received on Sun Feb 14 2010 - 16:59:15 CET