Re: relations aren't types?

> Then we agree, the scalar-ness is not a property of the type but of who
> is using it. Within your library where you choose a specific
> representation, the type is not scalar. Outside it is. But as you say,
> it's all the same type, so the scalar-ness cannot be a property of the
> type.
>
> There are layers of types in any system -- to a client of my date
> library, the date type is abstract. Within the date library, the date
> type might actually be a struct which is itself abstract. Within the
> language implementation, a struct is actually some bitvector. And
> finally within the processor, that sequence of bits is actually
> electrical potentials. None of these (well, except maybe the potentials)
> are fundamentally scalar, they're only scalar from the point of view of
> the layer above. I can always break through the abstraction barriers if
> I want to by unplugging the computer or waving a magnet around.

I agree that there are layers, but I disagree that we should be able to access the layers below any given abstraction. Doing so violates the physical data independence that the abstraction gives us in the first place. This is why I think there is something about the type itself that is scalar. There is no 'within the date library' in TTM. Date is a type available globally, and any user can take advantage of it, either as a scalar value, or by acessing some component of some representation of the value. The internal implementation (which is probably done in a lower-level language, or automated by the system entirely) is not even accessible in the database language. So the fact that a given scalar has structure at a lower level is not visible in the language. This is what makes them scalar. Received on Tue Jan 13 2004 - 07:13:10 CET