Re: RA with MV attributes
Date: Wed, 17 Jan 2007 02:23:12 GMT
Message-ID: <kMfrh.1888$1x.29903_at_ursa-nb00s0.nbnet.nb.ca>
Marshall wrote:
> On Jan 16, 4:48 pm, "David" <davi..._at_iinet.net.au> wrote:
>
>>David wrote:
>>
>>>Marshall wrote:
>>>
>>>>Interesting post. Some comments inline.
>>
>>>>On Jan 16, 12:40 am, "David" <davi..._at_iinet.net.au> wrote:
>>
>>>>>Definition: A relation r consists of a relation-type A(r) together
>>>>>with a set of tuples T(r), where each tuple is a map from each
>>>>>attribute a in A(r) to a subset of D(a).
>>
>>>>I realize it's becoming fashionable, but I still dislike the idea
>>>>that a relation "consists of" its type and its value, both.
>>>>It's type is its type and its value is its value; it doesn't
>>>>make sense to me otherwise. If we consider the relation
>>>>as being a combination of two things, we ought to be
>>>>able to consider those two things separately. In which
>>>>case we can ask the question, what is the type of a
>>>>relation's value? Presumably that is also its type, and
>>>>so we have infinite regress.
>>
>>>>Or consider how it sounds for a value of a non-parameterized
>>>>type: "An integer consists of a numeric-type int together with
>>>>an int." ???
>>
>>>>Yet another reason to dislike it is that it combines in a single
>>>>construct both a static construct and a dynamic one. It is
>>>>entirely reasonable to consider a system where types exist
>>>>at compile time and do not exist at runtime, and values exist
>>>>at runtime and do not exist at compile time. So how could we
>>>>combine them?
>>
>>>>Anyway, this is a diversion from your main point.
>>
>>>I agree with your points. Note that we can't define a join on two
>>>relation values without access to their type information. A weakly
>>>typed language that allows for joins on two relations would be forced
>>>to explicitly store the type together with the relation-value as part
>>>of the run-time state. As you suggest above, a strongly typed
>>>language allows values to be stored without explicit run time type
>>>information.
>>
>>>I regard the combination of type and value into a single construct as a
>>>convenience for the exposition.
>>
>>After thinking about it some more I've changed my mind. The join
>>operation needs to *calculate* the "type" of the result. Therefore
>>it seems better to regard the "type information" as part of the
>>relation value.
>
>
> The calculation of the result type can be performed knowing only
> the operand *types* and not the operand values. Yes, this could
> be deferred to runtime, but it doesn't have to be, and if it is, the
> same calculation will be done, with the same result, at every run,
> whereas the calculation could be performed just once, statically.
>
> Furthermore you will find that this property holds true of many
> functions over generic types. Consider a simple generic list
> type supporting a "get first element" operation. The type of
> the generic list is parameterized by the element type T.
> The type of getFirstElement() is int -> T. Hence the getFirstElement
> operation could also be said to "calculate the type" but if you
> code this up in, say, C++, the type calculating occurs entirely
> at compile time.
>
>
>
>>To avoid the infinite regress you should say >>1. A relation value r comprises both A(r) and T(r). >>2. The *type* of all relation values is the same: ie "relation" >>3. T(r) on its own is not a relation value >>4. The type of T(r) is "set of tuples", not "relation" >> >>BTW saying "r is a relation value" is naff. Really should say "r >>is a relation".
>
>
> That doesn't work for me. In 2, your proposal only considers
> abstract, parameterized type "relation" and doesn't consider
> concrete relation types. In 4, you draw a distinction between
> a set of tuples and a relation, but those are equivalent as far
> as I know. Can you explain the distinction?
>
>
>
>>I presume in a proper general purpose system strong typing of relvars >>won't work. Having to specify the type of relvars would be painful.
>
>
> Well, the term "strong typing" is fraught with peril, but assuming
> you mean "static typing" then I don't see why you think this
> would be an issue. Consider that a CREATE TABLE statement
> specifies the type of relvars.
>
>
>
>>It would also disallow conditional projection, such as >> >> relation r = test ? r1 : proj(r1,B) >> >>...not that I have an example of where that would be useful.
>
>
> I think you will find that *every* language with a ? : operator
> does not allow the two possible results to have incompatible types.
How does javascript evaluate the following?
o.left = oX + ( ! fNS4 ? "px" : 0 )
I have seen that a lot recently. The interesting thing--if I read it correctly--is the return type of the conditional fundamentally alters the preceding operation. ie. string concatenation vs. numeric addition
(Not that javascript is anywhere near as interesting as your discussion about static typing, though--sorry to interject.) Received on Wed Jan 17 2007 - 03:23:12 CET