Re: relations aren't types?

> In that case, all values are scalar since the only way you access any
> value is via "operators that extract new values from a given value".

Except that the operators that I can invoke on non-scalar types are aware of the logical structure of the values on which they are invoked. For example, projection over a relation involves naming the attributes involved in the projection:

A over { ID, Name };

> It's as if you're implying that there is some OTHER type, subsuming all
> the possible representations. Like dates, there is some pure date type
> which includes dates as structures, dates as strings, etc... But these
> are NOT the same type, since the operators which work on one will not
> work on the other.

The OTHER type IS the scalar type. Dates as structures don't exist, only the components of the possible representation, i.e., the year component, the month component, etc.,. Dates as strings are not dates, they are strings. It's just that an operator exists to extract the string representation of a date from a given date value.

Clearly, we could represent all values with scalar types, but if we did that, we would have to write the code for joins and other non-scalar operators ourselves. By partitioning values into scalar and non-scalar types, we can build a compiler that can write that code for us. Received on Thu Jan 15 2004 - 04:43:47 CET