Re: Thinking about MINUS

On Jan 8, 8:22 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> Marshall wrote:
>
> > Back to the original idea, which was what happens when you
> > join two relations with an attribute name in common but different
> > types for that attribute. Bob suggested using a union type, which
> > is sound, however I prefer calling it a type error.
>
> It is not an either/or thing. The resulting value is as I described, and
> if that value violates a constraint like "There are no union types",
> then it raises an error. However, how does one express the constraint if
> one does not recognize the value in the first place?

This perspective is very foreign to me, and I am not sure I understand it. Let me recast this in a different context, and see if I follow:

Suppose we attempt to evaluate the following program fragment:

  5 + "hello"

in a formal language with two data types, int and string, and the operation + takes two integer operands. Does the above comment apply? Your comment seems to be saying we need to have "express[ed]" constraints to have constraints, but it is possible to have constraints on a language simply by the *lack* of an appropriate evaluation rule. Or was the question rhetorical? Or did I completely misapprehend you?

> > (Also note that if we use the union type solution, the result will
> > always be empty, which is a signal that the operation doesn't
> > really do anything interesting.)
>
> Do I understand correctly that your position is: "Contradictions lack
> interest" ?

Heh.

Another example: consider the following function of two parameters:

int f(int a, int b) { return 0; }

Nothing wrong with it per se, no type errors or anything, but the fact that its return value is independent of the value of its arguments should at least arouse some suspicion as to its moral character.

> > If we use a name in two different scopes, and use it differently
> > in those two scopes, and we intend to merge the two scopes
> > together, we need to resolve that.
>
> Please note that the above provides additional context to explain the
> constraint. Whether it is an error depends on context.

I would agree; I would also claim that the particular formal language one is using is part of that context.

> > One of the things join does is merge two namespaces,
> > namely the attribute namespace
> > of each relation.
> I disagree. The join operation necessarily operates within a single
> namespace. Different invocations of the join operation may operate
> within separate namespaces, however.

Mmmm, not sure whether you understood me.

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. The demonstration of which is that we can reuse an attribute name in many different tables. So there are two different levels of namespaces, an "upper" one for relvar names and a "lower" one for attribute names.

When one does a join, each of the two operands brings with it a lower namespace, and the two namespaces have to be unified for the operation to succeed. The result of the join will be a new relation, with a new attribute namespace built (somehow) from the attribute namespaces of the two operands.

There are many approaches a formal system could take for how to handle what happens when one has a name used with two different types in the two namespaces:

1. create a union type
2. fail
3. automatically rename both of the conflicting names
4. don't require attribute names to be unique

(3 and 4 suck but illustrate that many approaches are possible.)

> Can you imagine a single proof or lemma in mathematics where the symbol
> x exists within multiple namespaces? In fact, one could look at a lemma
> as primarily introducing a separate namespace. As soon as one writes
> "Let x represent...", one defines the namespace of x.

Just so.

> > Well, I'm not explaining it very well. Hope to get more sleep tonight
> > than last night.
> I hope I get more sleep tonight than last night too--hopefully at least
> as much sleep as I got this afternoon! :P

Lately I have found that, while a large amount of alcohol makes me sleep poorly, a small amount of alcohol can help me sleep quite well. I'm exploring dessert wines in tiny glasses just before bedtime. Sweet.

Marshall Received on Tue Jan 09 2007 - 07:13:23 CET