Marshall wrote:
> That was a lot to digest. I read it all twice, and I think we are
> mostly
> on the same page. In particular I am quite convinced of the importance
> of names, and though you didn't mention it specifically, the value
> of an algebraic approach as per the Darwen article you referenced.
> (Which I also read, since it had been a long time since I first read
> it.)
>
> There are only a few things I want to respond to.
>
>
> On Jan 9, 8:58 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>
>>Agreed. In fact, if I recall correctly, someone once determined that the
>>lint warning for unused local variables correlated more with bugs than
>>any other warning or error message. Of course, that might be urban
>>legend. (I am relying solely on a ~20 year old memory, and I doubt I
>>read the original work.)
>
>
> Interesting!
>
>
>
>>>To my way of thinking, the database is a namespace that contains
>>>named relvars, or in SQL we say "tables." *Each* table is itself
>>>a separate namespace for attributes.
>>
>>When it comes to relations, I disagree, and I see no reason to
>>perpetuate the sins of SQL.
>
>
> Hmmm. Does this mean that you feel that all the attributes of all
> relations are in a single namespace, and if we use a name to mean
> a particular thing in one table we must necessarily use it the same
> way in another? Certainly I feel that they are all *potentially* in
> the same namespace, precisely *because* of natural join, but
> I'm not sure that I feel the need to impose any restrictions on
> the use of names across tables before any join occurs. (Particularly
> given the presence of a renaming mechanism.)
>
>
>
>>We have a formalism for expressing predicates as constraints. Data types
>>are merely constraints in those predicates. The manipulation rules spell
>>out what to do with those constraints in various situations, and the
>>rules differ from one situation (ie. operation) to another.
>
>
> There are some more aspects to this. One thing that is often left
> out of these discussions is the difference between static and
> dynamic constraints. That is, constraints that may be checked
> merely by looking at the form of an expression without regards
> to the contents of the variables referenced in the expression,
> and those that necessitate the examination, at each evaluation
> of the expression, of the value of each variable.
>
> Type constraints are typically entirely static, whereas many
> kinds of common database constraints, such as foreign key
> constraints, are necessarily runtime checks.
>
> I mention this because, while in general I agree that
> type constraints are simply a kind of general constraint,
> I believe that it is important to distinguish between
> static and dynamic constraints, as they will not be
> handled the same. However I am not entirely clear
> how to expose this difference to the programmer. The
> traditional method, in which type constraints are exclusively
> static and check constraints are exclusively dynamic,
> does not satisfy me.
>
>
>
>>To join the attributes, we must agree to use the intersection of their
>>domains. This suggests the data type must be a subtype of both
>>attributes. Joining reals with integers, one necessarily ends up with
>>integers. In fact, it should be the most general common subtype or least
>>specific common subtype of the declared types.
>>
>>Thus for completely disjoint declared types, the data type of the
>>resulting attribute is the universal subtype not the universal
>>supertype. The universal subtype, of course, has an empty set of values
>>and the union of all operations.
>
>
> If we are speaking of our mathematical analysis of a formal system,
> then I agree. If we are speaking of a formal system itself, then I
> would point out that that system may not be one in which the
> universal supertype or universal subtype exist. Indeed, it may
> not have subtyping at all.
>
> Anyway, thanks for the lengthy reply.
>
>
> Marshall
>
Received on Wed Jan 10 2007 - 07:49:07 CST
