Re: relations aren't types?

> Maybe we should look at other type systems. What sorts of types do most
> type systems have? Product types, like the types of rows in relations.
> Sum types, like enum. Recursively-defined sum types, like lists.
> Polymorphic type constructors, like lists, vectors, or functions. Base
> types like integers.
>
> Types are types -- I don't understand your insistence on calling some
> types scalar and other types not scalar. What's the difference?

Why call relation types relation types? The difference is that they are different types of values. They are subject to different treatment in the language and therefore the logical model. I must use different constructs to create them and specify them. Certainly they are also values, and I can invoke operators that take them as arguments, but that doesn't mean there isn't value in categorizing them the same way we categorize other types of values (relation, tuple, bag, set, array, list, collection, etc.). In order to explain how to use our language, we must have some name for the concept. You called them base types in the above paragraph. We are suggesting, like TTM, that there is a good name for them, and scalar is that name.

> And I have to ask, what's an example of a user-defined scalar type?

create type Degree
{
  representation Degree
  {
    Hour : Integer,
    Minute : Integer,
    Second : Decimal
  }
};

create type Coordinate
{
  representation Coordinate
  {
    Latitude : Degree,
    Longitude : Degree
  }
};

These are scalar types because they expose no logical structure to the user. The type specifier is simply the user-supplied name of the type. A non-scalar type does expose logical structure to the user, as evidenced by the type specifier. For example:

relation { Zipcode : String, CentralCoordinate : Coordinate }; Received on Fri Jan 09 2004 - 17:47:34 CET