Re: MV Keys

In article <1141938659.191917.162110@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
marshall.spight@xxxxxxxxx says...
Jon Heggland wrote:
marshall.spight@xxxxxxxxx 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
.

Relevant Pages

  • Re: man page syntax for +script
    ... The man pages for [bind] and [comm hook] both describe how you can either replace the current script or append to it, but they give slightly different syntaxes. ... But the syntax for makes it appear that the + and the script are separate arguments, and that caused me some confusion. ... you have a distorted view of what is syntax and what is semantics in Tcl. ...
    (comp.lang.tcl)
  • Re: man page syntax for +script
    ... The man pages for and both describe how you can either replace the current script or append to it, but they give slightly different syntaxes. ... But the syntax for makes it appear that the + and the script are separate arguments, and that caused me some confusion. ... The plus is a semantic definition that these two unrelated commands put on their last argument, expr has a very different semantic definition of "+". ... you have a distorted view of what is syntax and what is semantics in Tcl. ...
    (comp.lang.tcl)
  • Re: they mention various metaphors and ramble about various concerns (Re: Kuratowski Ordered Pair)
    ... it means to call x the semantics for syntax y? ... (kind of like your archaic understanding of syntax-semantics ... and i did not see much of substance in response ...
    (sci.math)
  • Re: Relative merits of Lisp-1 vs. Lisp-2?
    ... language syntax and semantics unless you think that by adding these ... clearly semantics will not. ... be handwaved away, too, layer after layer. ... Clearly there can be another projection ...
    (comp.lang.lisp)
  • Re: Queries and OO
    ... Semantics are very important, and syntax just represents ... certain semantics than another, but they're really all just cake. ... > have to use a very terse and formal language. ... collection has the target object replaced by the message's result ...
    (comp.object)