Re: relations aren't types?

> I say Collection is a type class because many different types can be
> used AS collections. But on second though I'm probably wrong about Bag
> and Set since these do have specific restrictions on the data they can
> hold, so you're right, they are also just polymorphic types.

Ok, let me see if I have this right. Relation is a polymorphic type because I can define a new relation type with attributes of arbitrary types, and it becomes a compile-time verifiable construct. Would I be right in saying that C++ templates are examples of polymorphic types? I have never thought of relation types in that way. It's always just been a feature of the language, a compiler implementation issue.

> But records (like the two you user-defined "scalars" you mentioned
> earlier) are? Since records and tuples are isomorphic I don't understand
> this.

Scalar types are not exactly records. A scalar type may have multiple possible representations. For example:

create type Date
{
  representation Date { Hour : Integer, Minute : Integer, Second : Integer },
  representation AsString { AsString : String } };

I would agree that a tuple type could be considered isomorphic to a given possible representation of a scalar type, but not to the scalar type itself.

> >> 2. that you want to be able to create new "scalar" types but using a
> >> different syntax for them than for other algebraic datatypes.
> > I don't know what an algebraic type is as opposed to a non-algebraic
> > type.
>
> Here's a pretty good description at foldoc (though a google search
> wasn't very helpful):
> http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=algebraic+datatype

I read the definition, and I have to say it was beyond me. I thought I understood it until it said that list was an algebraic type. If tuple is an algebraic type because it defines a set of values by combining values of other types, then how is list an algebraic type? I suppose it also defines a set of values by combining values of other types, but it's open ended, I mean I can always add another value to the list. Tuple is not open ended like this.

> Personally I think extra syntax obscures or even inhibits opportunities
> for generalization. Sugar can be provided for common type constructors,
> like lists and records, but these can be trivially transformed into the
> prefix notation of user-defined types so it's ok.

I agree that if a given construct can be implemented as a short-hand for some more primitive construct then it should, but I'm not convinced that the type system given in TTM can be reduced.

> I definitely can't
> take C# seriously as an example of a good type-definition syntax.

Okay, Pascal has different type generators for records and sets. Probably not any better.

> So indeed it is the difference between abstract and concrete datatypes.
> There's nothing inherent in the type "Degree" which makes it scalar,
> only how you happen to be using it. In languages with good type systems
> (I'm thinking Haskell) which don't create artificial distinctions
> between system and user-defined types, it's much more obvious that the
> distinction you're talking about is subjective.

I think we are going to have to clarify abstract and concrete types. I'm pretty sure I know what you mean, but I would like to be certain. An abstract type is a record or class, while a concrete type is a system-provided construct like list or array. Right? At any rate, I'm not sure I agree with your characterization here. There _is_ something inherent in Degree that makes it scalar, namely that it has multiple possible representations, all of which are encapsulated within the type. It has no visible logical structure, unlike tuple and relation types. This difference is critical because the logical structure of these types is part of how we manipulate tuple and relation values.

> > By designing the language to be aware of relation and tuple types, we
> > can provide much more intuitive mechanisms for dealing with values of
> > these types.
>
> Maybe that's because you're used to languages where these "intuitive
> mechanisms" have to be built in to the language because they can't be
> expressed IN the language. What intuitive mechanisms did you have in
> mind?

That's an interesting possibility. Let me describe some of the features I consider most important. First and foremost, the language exposes the logical model. It forms the conceptual level of the database, and so it is the entire system with which the user interacts. From a database perspective, the most important types of values are scalars (system and user-defined of arbitrary complexity), tuples, and relations. We want a language that allows us to write relational expressions as easily as possible. We want to be able to say A join B and A where ID = 5. We also want to be able to define relation variables as easily as possible. Ideally, create table and create view statements that allow us to tell the system what we want with a minimum of syntactic footwork. It seems to me that these requirements dictate special syntax in the language, but if there was a way to do it as short-hand for something, I'd certainly be interested. Received on Sun Jan 11 2004 - 08:38:07 CET