Re: MV Keys

In article <1141938659.191917.162110_at_i40g2000cwc.googlegroups.com>, marshall.spight_at_gmail.com says...
> Jon Heggland wrote:
> > marshall.spight_at_gmail.com says...
>
> [... lots of disagreement ...]
>
> I was thinking about this thread, and how we seem to be talking
> past each other, and an idea occurred to me. I notice that much
> of what you're talking about is syntactic issues, while I'm trying
> to focus on the semantic. What if we're both right?
>
> What if, in fact, the element-of-a-set is a necessary *syntactic*
> construct, but not a necessary *semantic* one?

You may be onto something, but I would say it is the other way around. You can't "semantically" have sets without elements. Whether you let users of your system have access to such elements outside the context of a set, is a design decision---which intuitively sounds more syntactic than semantic to me. I don't feel those labels fit all that well, though.

> I notice you've brought up the issue of how one writes a relation
> literal a few times. Certainly, one needs a *syntactic* way to
> distinguish when one is entering values for one "row" and when
> one moves on to the next row.
>
> But at the semantic level, perhaps there is no need for a separate
> type, a separate abstraction, to model that element. The RA
> has no tuple-level operations, after all.

I'd rather say that in *theory*, there is / must be a distinction between relations and tuples. In *practise*, you may not need to worry about it. A weak analogy: You don't need to fiddle with tuples in order to use relations, like you don't need to fiddle with bits to work with integers. The tuples and the bits still exist, though.

As for the RA not having tuple operations, true, but I find it very convenient to be able to talk about tuples when explaining how the RA operators work to my students.

Anyway, I think there are two relatively independent issues here. One is whether your system will be complete and usable without tuple types. That is to a certain degree a matter of taste; I'll admit it may be possible.

The other issue is your redefinition of "tuple" and the inconsistencies I claim arise because of that. I have the impression you dodge all my questions about infinite nesting of relations (a tuple being a set of one tuple which is a set of one tuple and so on ad infinitum), so to my mind, you don't take your own definition seriously. I'd guess you have discovered that you don't need tuple types/variables, and so you reuse the "tuple" term for convenience---without really thinking about the theoretical consequences. I guess that since you are convinced your system can work, you see no fault with your tuple definition---but I say that your system might work because you don't really take the consequences of your definition.

> > The problem is that you contradict yourself. You say (1,b) is a tuple,
> > and you say that a tuple is a set. (1,b) is not a set.
>
> Syntactically, that is true. Semanticly, it may not be true.

No, the other way around. Through creative use of syntax, you can *define* (1,b) to represent a set (though you sun into trouble if you want it to represent the same set as { (1,b) }---what does (1,b) represent in the second case?). But I am using standard set notation here. I can say "Syntactically, 'orange' is not a number; semantically it may be", but it is not very sensible to say, IMHO.

> > Do you also agree that the cardinality-1 relation literals must (or at
> > least should) be specified in such a way that the compiler knows that
> > the cardinality is 1?
>
> Sure. How could it not know?

When a method in Java takes an array as a parameter, it does not know the size of it at compile time. I was a bit muddled in my thinking, though. The compiler of course knows the size of the literal, but the size of an array is not part of its type. So you cannot in your system define a procedure that requires a tuple as an argument---but you don't need to or want to anyway?

> > I believe tuple types as distinct from relation types exists by
> > necessity/definition, since { (1,b) } is distinct from (1,b)
>
> What if "(1, b)" is just shorthand syntax for "{ (1,b) }"?

Then (1,b) cannot be shorthand for { (1,b) } in the second expression. It may be possible to do, but you will have a horribly confusing syntax/grammar, IMO.

> > Yes, I've seen this idea in TTM, and I think it is elegant (in
> > theory, but cumbersome in practise).
>
> How well it works in practice will have a lot to do with
> how well the idea is executed. A convenient syntax could
> help a lot.

Sure. I guess what one does in practise, is to use conventional syntax, and just define the result using such relational terms. I.e. more an intellectual game than an actual language design / operator implementation strategy.

> > I just wonder how the code implementing the
> > (infinite) relation "add" looks like. Do you envision this as
> > implemented in a separate language and thus irrelevant to this
> > discussion? Should the users / developers be able to make their own
> > "operation relations" à la "add"?
>
> In the specific case of add, it's likely to be a built-in, to take
> advantage of machine instructions, but that's probably not
> what you were asking. No, I don't envision a separate language;
> users will certainly be able to write their own functions; it
> would not be a general purpose language otherwise.

But they won't be able to use anything but relation types? I have a hard time envisioning how this will work, but maybe I'm just unimaginative. :)

> > Fair enough. I disagree on both points, however. I think you need
> > special syntax and behaviour for tuples; not considering them distinct
> > from relations is therefore confusing, not simple.
>
> Special syntax: okay, sure; if only for the purposes of constructing
> relation literals.
>
> Behavior? What behavior do we need for tuples?

I was thinking of the ensure-that-it-has-cardinality-one functionality.

> So, I can see how you could argue that this is cumbersome, or
> likely to be verbose, or badly done, or whatever. I can see
> how you can say that I've removed a valuable, useful abstraction,
> the tuple.
>
> But I don't see any contradiction, or any lack of computational
> power or generality.

My main issue is your definition of relation, and your use of the term "tuple". You say that a relation is a subset of a cross product of sets. An element of such a product is called a tuple; this is really not up for debate, I think. It is *not* a set. When you say that it is, you are gainsaying elementary set theory. You don't need to do this in order to simplify your system by removing tuple types!

> > I also believe that
> > not taking advantage of tuples being fixed-size (as opposed to relations
> > with a variable number of tu... I mean elements:) makes the
> > implementation more complicated than it needs to be.
>
> I'm not sure what you mean by "take advantage." If you mean at
> the implementation level, nothing prevents me from taking such
> advantage; it's possible to encapsulate the singleton idea.

But if you implement relations and tuples differently, what is the point of considering them to be the same thing?

> If
> you mean at the syntactic level, again, I can have whatever
> syntactic level construct I want, even within the given semantics.
> At the semantic level, the concept of tuples is redundant, and
> removing it reduces complexity.
>
>
> > And how would you do the variable assignment (if that is applicable---do
> > you plan to have string variables?)?
>
> I had assignment for a while, but I dropped it; it was redundant
> with UPDATE.

There are some who say UPDATE *is* assignment. :) But are you saying that you don't have scalar variables, only relvars? Or that you use UPDATE to change a scalar variable?

-- 
Jon