Re: relations aren't types?

> I think you're confusing types with type classes, and types with values,
> in the above. Certainly if "they" are "relation types", then they are
> NOT "also values".

Sorry, my terminology was sloppy. "They" refers to types in the above paragraph. When I said values, I meant values of a given type within some type category. I am certainly not claiming that types are values.

> Of the "types of values" you list, some are (usually) type classes or
> abstract data types (bag, set, collection), while others are just plain
> polymorphic types (relation, list).

I don't know what you mean by polymorphic types. If you mean that they can contain values of different types, then why are bag, set, and collection not polymorphic types. I'm sorry, I don't know what you mean by this.

> Normally I'd consider atomic types provided by the system, like Char or
> Int, to be scalar types. What confuses me is:
> 1. that you claim that tuples (an algebraic datatype) are scalar but
> lists (also an algebraic datatype) aren't, and

Tuples are not scalar. Only scalar types are scalar. I know it sounds facetious but I don't know how to say it more plainly. If a given type is of some type category other than scalar (tuple, relation, etc) then it is not a scalar type. Bob is thoroughly confused on this issue, and has put words into my mouth in this regard. He is the one that claimed that all types are scalar, and I cannot reiterate strongly enough that he is not using the term scalar as it is defined in TTM.

> 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. I do, however want to use different syntax to define new scalar types, just as I would want different syntax to define tuple types, and different syntax to define relation types. In general, if a language supports a specific category of type, then it should have different syntax for dealing with values of those types. For example, C# has a different type generator for classes than for enums.

> > 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.
>
> I have no idea what "logical structure" is, but it almost sounds like
> abstract datatypes are scalar but concrete datatypes aren't?

For me, the simplest explanation (the one where I finally understood the difference) is that if the type specifier describes the structure of values of the type, that is logical structure. A relation type specifier exposes the attributes of relation values of that type (relation { ID : Integer }). An array type specifier exposes the type of the elements that values of that type contain (array[Integer]). A scalar type specifier is simply the name of the type in question, like Integer, Degree, Coordinate, etc. By looking at a scalar type specifier, the user cannot determine any logical structure for values of that type.

> There exist languages in which you can use the same syntax to define a
> relation type as to define a date type or any other type you want. Are
> you saying that by not labeling some types as scalar (based on
> conditions which still sound ill-defined to me) and giving them a
> different syntax, these languages are less powerful or easy to use?

Yes, exactly. I could certainly use a language like C to describe an abstract data type which would allow me to model relations, but the C language itself would not give me any help in dealing with these 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. Received on Sat Jan 10 2004 - 06:41:52 CET