Re: relations aren't types?

> I have yet to see a useful definition of scalar that does not include
> everything one can represent in a finite number of bits.

Why is this a requirement for a useful definition of scalar? Why does a finite number of bits even matter? It sounds like you are describing the physical representation of the value, which can be done with a finite number of bits for every value of every type, by definition. Why does this even enter into the logical level of the language?

> "A join B" requires you know the attributes of something? What attributes
> must you know?

You can invoke "A join B" without knowing the attributes, but what does the result mean? In order to answer that question you must know the attributes over which the join is performed, and in order to deduce the cardinality of the result you must also know the functional dependencies of those attributes that hold in the source relations. At any rate, this is a special case, and as such falls under the qualification "in general". I don't need to know the attributes of a given relation to invoke Count(A) either, but that does not make relation any less a non-scalar type. In order to inovke a non-trivial project, for example, I do need to know the attributes, and the fact that relation is a non-scalar type means I do know them. The type contains the names of the attributes involved, i.e. user-visible components. For scalar types, the type specifier is just the name. Received on Wed Dec 31 2003 - 07:52:51 CET