Re: MV Keys

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?

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.

> > > Yet (1,b) is obviously not a relation, and equally obviously not a tuple
> > > by your definition! It is not the subset of anything, because it is not
> > > a set. Do you still not see the problem?
> >
> > Yes, I still don't see the problem.
>
> 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.

> 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?

> 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) }"? Note that the parentheses in the second expression are not the same kind of parentheses as in the first expression; it is not the case that a particular token has to have the same meaning everywhere it appears in a grammar. For example, in Java, "{" introduces the beginning of the body of a class in some production, and introduces the body of a method in another production; they are not the same "{".

> 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.

The biggest problem with the idea is the fact that it leads to function arguments being identified by-name rather than the more customary by-posititon. But Smalltalk has done this for years and I've never heard anyone complain. (OTOH, Smalltalk isn't particularly popular.)

> 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.

> > Certainly not! There were two sentences after "it's simpler." The first
> > was about interface and the second about implementation. There
> > are benefits at both levels. But that doesn't mean I'm mixing them.
>
> 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? All of the tuple level operations I can think of are redundant with relational operations.

In fact, I'll make this claim: all you need is relations and scalars, and operations on same. All you need to do with scalars is invoke functions on them, and this can be done with a specific relational operator, natural join. There is no need to have any operation to extract elements from relations, nor any need to extract scalars from relations, as long as one can invoke functions on them.

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.

> 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. 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.

> Whether or not usable
> tuple types are required is more like whether or not you need list types
> when you have relation types. Amusingly, it seems we have taken the
> reverse positions in this case. :)

Yes, I had noticed that too; it is amusing.

(Minor note: I don't claim that lists are necessary, just that they are useful and convenient.)

Marshall Received on Thu Mar 09 2006 - 22:10:59 CET