 | |
#1
 
| |||
| |||
|
RL notation -
02-07-2008
, 02:21 PM
|
Brass tacks: X(x) -- the domain R(a, b) -- the relation X & (x=a) & (x=b) => R X is a relation with one attribute, x. R is a relation with attributes a and b, taken from the members of X The phrase "(x=a)" denotes the infinite relation of attributes a and x where a = x. In set builder notation: {(x, a) | x in X and x = a} "&" is natural join. So X & (x=a) joins X with (x=a), creating a new relation with attributes x and a. X & (x=a) & (x=b) does the same thing, so now we have {(x, a, b) | x in X and x = a and x = b} "=>" is the generalized subset operator. It takes two relation operands, and evaluates to true if the left operand has a superset of the attributes, and a subset of the elements of the right operand. |
notation:-) It is imperfect for at least two reasons:
1. Equality relation, is it some kind of constant in the RA? Also the
"=" symbol in the (a=b) conflicts with the equality among relations.
Two levels of equality is something people never dealt before?
2. Explicit column variables. Having two sorts of symbols -- realtion
and attribute variables -- makes RL expressions less pretty.
#2
| |||
| |||
|
|
Marshall wrote: Brass tacks: X(x) -- the domain R(a, b) -- the relation X & (x=a) & (x=b) => R X is a relation with one attribute, x. R is a relation with attributes a and b, taken from the members of X The phrase "(x=a)" denotes the infinite relation of attributes a and x where a = x. In set builder notation: {(x, a) | x in X and x = a} "&" is natural join. So X & (x=a) joins X with (x=a), creating a new relation with attributes x and a. X & (x=a) & (x=b) does the same thing, so now we have {(x, a, b) | x in X and x = a and x = b} "=>" is the generalized subset operator. It takes two relation operands, and evaluates to true if the left operand has a superset of the attributes, and a subset of the elements of the right operand. I suspect only 3 people in the world are comfortable with this notation:-) |
Quote:
|
It is imperfect for at least two reasons: 1. Equality relation, is it some kind of constant in the RA? Also the "=" symbol in the (a=b) conflicts with the equality among relations. Two levels of equality is something people never dealt before? |
for someone as deep into parsing as you. What is worse,
I write relational equality as if it had precedence lower than
&, and the other equality as if it had higher precedence.
In general, I have been trying to completely separate the
relational operators and the scalar operators. Eliminating
booleans in favor of DEE and DUM has made this easier,
but we still have the problem of comparison and equality.
If we use => for comparison, this is pleasing because
the generalized subset is closely semantically related
to implication. (In fact some books write implication with
the subset character.) It vaguely feels like it's pointing
the wrong way, though. And what's the reverse? <=?
That's the usual programming language scalar less-than-
or-equal. So maybe it's "=<"? I dunno. Maybe it should
be << and >>. And then you still have the = problem,
and the precedence thereof.
I'm not even absolutely sure there are two different
equalities, though. Maybe there is just the one equality,
and we define the relational comparison with it. Vice versa
also works. But we need *something* besides just the
two lattice operators or we can't compare relations.
Quote:
|
2. Explicit column variables. Having two sorts of symbols -- realtion and attribute variables -- makes RL expressions less pretty. |
they should be syntactically distinct? Because I can recall
you writing similar expressions, but with a different syntax.
X join {(x, y) | x = y}
I would write:
X & x = y
and you might write
X /\ `x=y`
Yes, there is some concern about relation variables
and attribute names appearing at the same lexical
level in expressions, but my tendency is to believe the
brevity is worth the risk. Attributes and variables are
all declared ahead of time, after all, so there is
no direct source of ambiguity. The one real concern
I have is with code changing over time. What if a
name that appears free in an expression, and is
thereby classified as an attribute name (as y is
above) is, in a later version of a file, used at a
higher lexical scope, changing the meaning of
existing expressions? That seems like a bad thing,
so it might be required to declare attributes before
use that would otherwise appear free.
Marshall
#3
| |||
| |||
|
|
Marshall wrote: Brass tacks: X(x) -- the domain R(a, b) -- the relation X & (x=a) & (x=b) => R X is a relation with one attribute, x. R is a relation with attributes a and b, taken from the members of X The phrase "(x=a)" denotes the infinite relation of attributes a and x where a = x. In set builder notation: {(x, a) | x in X and x = a} "&" is natural join. So X & (x=a) joins X with (x=a), creating a new relation with attributes x and a. X & (x=a) & (x=b) does the same thing, so now we have {(x, a, b) | x in X and x = a and x = b} "=>" is the generalized subset operator. It takes two relation operands, and evaluates to true if the left operand has a superset of the attributes, and a subset of the elements of the right operand. I suspect only 3 people in the world are comfortable with this notation:-) |
Quote:
|
It is imperfect for at least two reasons: 1. Equality relation, is it some kind of constant in the RA? Also the "=" symbol in the (a=b) conflicts with the equality among relations. Two levels of equality is something people never dealt before? |
for someone as deep into parsing as you. What is worse,
I write relational equality as if it had precedence lower than
&, and the other equality as if it had higher precedence.
In general, I have been trying to completely separate the
relational operators and the scalar operators. Eliminating
booleans in favor of DEE and DUM has made this easier,
but we still have the problem of comparison and equality.
If we use => for comparison, this is pleasing because
the generalized subset is closely semantically related
to implication. (In fact some books write implication with
the subset character.) It vaguely feels like it's pointing
the wrong way, though. And what's the reverse? <=?
That's the usual programming language scalar less-than-
or-equal. So maybe it's "=<"? I dunno. Maybe it should
be << and >>. And then you still have the = problem,
and the precedence thereof.
I'm not even absolutely sure there are two different
equalities, though. Maybe there is just the one equality,
and we define the relational comparison with it. Vice versa
also works. But we need *something* besides just the
two lattice operators or we can't compare relations.
Quote:
|
2. Explicit column variables. Having two sorts of symbols -- realtion and attribute variables -- makes RL expressions less pretty. |
they should be syntactically distinct? Because I can recall
you writing similar expressions, but with a different syntax.
X join {(x, y) | x = y}
I would write:
X & x = y
and you might write
X /\ `x=y`
Yes, there is some concern about relation variables
and attribute names appearing at the same lexical
level in expressions, but my tendency is to believe the
brevity is worth the risk. Attributes and variables are
all declared ahead of time, after all, so there is
no direct source of ambiguity. The one real concern
I have is with code changing over time. What if a
name that appears free in an expression, and is
thereby classified as an attribute name (as y is
above) is, in a later version of a file, used at a
higher lexical scope, changing the meaning of
existing expressions? That seems like a bad thing,
so it might be required to declare attributes before
use that would otherwise appear free.
Marshall
#4
| |||
| |||
|
|
Marshall wrote: Brass tacks: X(x) -- the domain R(a, b) -- the relation X & (x=a) & (x=b) => R X is a relation with one attribute, x. R is a relation with attributes a and b, taken from the members of X The phrase "(x=a)" denotes the infinite relation of attributes a and x where a = x. In set builder notation: {(x, a) | x in X and x = a} "&" is natural join. So X & (x=a) joins X with (x=a), creating a new relation with attributes x and a. X & (x=a) & (x=b) does the same thing, so now we have {(x, a, b) | x in X and x = a and x = b} "=>" is the generalized subset operator. It takes two relation operands, and evaluates to true if the left operand has a superset of the attributes, and a subset of the elements of the right operand. I suspect only 3 people in the world are comfortable with this notation:-) |
Quote:
|
It is imperfect for at least two reasons: 1. Equality relation, is it some kind of constant in the RA? Also the "=" symbol in the (a=b) conflicts with the equality among relations. Two levels of equality is something people never dealt before? |
for someone as deep into parsing as you. What is worse,
I write relational equality as if it had precedence lower than
&, and the other equality as if it had higher precedence.
In general, I have been trying to completely separate the
relational operators and the scalar operators. Eliminating
booleans in favor of DEE and DUM has made this easier,
but we still have the problem of comparison and equality.
If we use => for comparison, this is pleasing because
the generalized subset is closely semantically related
to implication. (In fact some books write implication with
the subset character.) It vaguely feels like it's pointing
the wrong way, though. And what's the reverse? <=?
That's the usual programming language scalar less-than-
or-equal. So maybe it's "=<"? I dunno. Maybe it should
be << and >>. And then you still have the = problem,
and the precedence thereof.
I'm not even absolutely sure there are two different
equalities, though. Maybe there is just the one equality,
and we define the relational comparison with it. Vice versa
also works. But we need *something* besides just the
two lattice operators or we can't compare relations.
Quote:
|
2. Explicit column variables. Having two sorts of symbols -- realtion and attribute variables -- makes RL expressions less pretty. |
they should be syntactically distinct? Because I can recall
you writing similar expressions, but with a different syntax.
X join {(x, y) | x = y}
I would write:
X & x = y
and you might write
X /\ `x=y`
Yes, there is some concern about relation variables
and attribute names appearing at the same lexical
level in expressions, but my tendency is to believe the
brevity is worth the risk. Attributes and variables are
all declared ahead of time, after all, so there is
no direct source of ambiguity. The one real concern
I have is with code changing over time. What if a
name that appears free in an expression, and is
thereby classified as an attribute name (as y is
above) is, in a later version of a file, used at a
higher lexical scope, changing the meaning of
existing expressions? That seems like a bad thing,
so it might be required to declare attributes before
use that would otherwise appear free.
Marshall
#5
| |||
| |||
|
|
Marshall wrote: Brass tacks: X(x) -- the domain R(a, b) -- the relation X & (x=a) & (x=b) => R X is a relation with one attribute, x. R is a relation with attributes a and b, taken from the members of X The phrase "(x=a)" denotes the infinite relation of attributes a and x where a = x. In set builder notation: {(x, a) | x in X and x = a} "&" is natural join. So X & (x=a) joins X with (x=a), creating a new relation with attributes x and a. X & (x=a) & (x=b) does the same thing, so now we have {(x, a, b) | x in X and x = a and x = b} "=>" is the generalized subset operator. It takes two relation operands, and evaluates to true if the left operand has a superset of the attributes, and a subset of the elements of the right operand. I suspect only 3 people in the world are comfortable with this notation:-) |
Quote:
|
It is imperfect for at least two reasons: 1. Equality relation, is it some kind of constant in the RA? Also the "=" symbol in the (a=b) conflicts with the equality among relations. Two levels of equality is something people never dealt before? |
for someone as deep into parsing as you. What is worse,
I write relational equality as if it had precedence lower than
&, and the other equality as if it had higher precedence.
In general, I have been trying to completely separate the
relational operators and the scalar operators. Eliminating
booleans in favor of DEE and DUM has made this easier,
but we still have the problem of comparison and equality.
If we use => for comparison, this is pleasing because
the generalized subset is closely semantically related
to implication. (In fact some books write implication with
the subset character.) It vaguely feels like it's pointing
the wrong way, though. And what's the reverse? <=?
That's the usual programming language scalar less-than-
or-equal. So maybe it's "=<"? I dunno. Maybe it should
be << and >>. And then you still have the = problem,
and the precedence thereof.
I'm not even absolutely sure there are two different
equalities, though. Maybe there is just the one equality,
and we define the relational comparison with it. Vice versa
also works. But we need *something* besides just the
two lattice operators or we can't compare relations.
Quote:
|
2. Explicit column variables. Having two sorts of symbols -- realtion and attribute variables -- makes RL expressions less pretty. |
they should be syntactically distinct? Because I can recall
you writing similar expressions, but with a different syntax.
X join {(x, y) | x = y}
I would write:
X & x = y
and you might write
X /\ `x=y`
Yes, there is some concern about relation variables
and attribute names appearing at the same lexical
level in expressions, but my tendency is to believe the
brevity is worth the risk. Attributes and variables are
all declared ahead of time, after all, so there is
no direct source of ambiguity. The one real concern
I have is with code changing over time. What if a
name that appears free in an expression, and is
thereby classified as an attribute name (as y is
above) is, in a later version of a file, used at a
higher lexical scope, changing the meaning of
existing expressions? That seems like a bad thing,
so it might be required to declare attributes before
use that would otherwise appear free.
Marshall
#6
| |||
| |||
|
|
Marshall wrote: Brass tacks: X(x) -- the domain R(a, b) -- the relation X & (x=a) & (x=b) => R X is a relation with one attribute, x. R is a relation with attributes a and b, taken from the members of X The phrase "(x=a)" denotes the infinite relation of attributes a and x where a = x. In set builder notation: {(x, a) | x in X and x = a} "&" is natural join. So X & (x=a) joins X with (x=a), creating a new relation with attributes x and a. X & (x=a) & (x=b) does the same thing, so now we have {(x, a, b) | x in X and x = a and x = b} "=>" is the generalized subset operator. It takes two relation operands, and evaluates to true if the left operand has a superset of the attributes, and a subset of the elements of the right operand. I suspect only 3 people in the world are comfortable with this notation:-) |
Quote:
|
It is imperfect for at least two reasons: 1. Equality relation, is it some kind of constant in the RA? Also the "=" symbol in the (a=b) conflicts with the equality among relations. Two levels of equality is something people never dealt before? |
for someone as deep into parsing as you. What is worse,
I write relational equality as if it had precedence lower than
&, and the other equality as if it had higher precedence.
In general, I have been trying to completely separate the
relational operators and the scalar operators. Eliminating
booleans in favor of DEE and DUM has made this easier,
but we still have the problem of comparison and equality.
If we use => for comparison, this is pleasing because
the generalized subset is closely semantically related
to implication. (In fact some books write implication with
the subset character.) It vaguely feels like it's pointing
the wrong way, though. And what's the reverse? <=?
That's the usual programming language scalar less-than-
or-equal. So maybe it's "=<"? I dunno. Maybe it should
be << and >>. And then you still have the = problem,
and the precedence thereof.
I'm not even absolutely sure there are two different
equalities, though. Maybe there is just the one equality,
and we define the relational comparison with it. Vice versa
also works. But we need *something* besides just the
two lattice operators or we can't compare relations.
Quote:
|
2. Explicit column variables. Having two sorts of symbols -- realtion and attribute variables -- makes RL expressions less pretty. |
they should be syntactically distinct? Because I can recall
you writing similar expressions, but with a different syntax.
X join {(x, y) | x = y}
I would write:
X & x = y
and you might write
X /\ `x=y`
Yes, there is some concern about relation variables
and attribute names appearing at the same lexical
level in expressions, but my tendency is to believe the
brevity is worth the risk. Attributes and variables are
all declared ahead of time, after all, so there is
no direct source of ambiguity. The one real concern
I have is with code changing over time. What if a
name that appears free in an expression, and is
thereby classified as an attribute name (as y is
above) is, in a later version of a file, used at a
higher lexical scope, changing the meaning of
existing expressions? That seems like a bad thing,
so it might be required to declare attributes before
use that would otherwise appear free.
Marshall
#7
| |||
| |||
|
|
Marshall wrote: Brass tacks: X(x) -- the domain R(a, b) -- the relation X & (x=a) & (x=b) => R X is a relation with one attribute, x. R is a relation with attributes a and b, taken from the members of X The phrase "(x=a)" denotes the infinite relation of attributes a and x where a = x. In set builder notation: {(x, a) | x in X and x = a} "&" is natural join. So X & (x=a) joins X with (x=a), creating a new relation with attributes x and a. X & (x=a) & (x=b) does the same thing, so now we have {(x, a, b) | x in X and x = a and x = b} "=>" is the generalized subset operator. It takes two relation operands, and evaluates to true if the left operand has a superset of the attributes, and a subset of the elements of the right operand. I suspect only 3 people in the world are comfortable with this notation:-) |
Quote:
|
It is imperfect for at least two reasons: 1. Equality relation, is it some kind of constant in the RA? Also the "=" symbol in the (a=b) conflicts with the equality among relations. Two levels of equality is something people never dealt before? |
for someone as deep into parsing as you. What is worse,
I write relational equality as if it had precedence lower than
&, and the other equality as if it had higher precedence.
In general, I have been trying to completely separate the
relational operators and the scalar operators. Eliminating
booleans in favor of DEE and DUM has made this easier,
but we still have the problem of comparison and equality.
If we use => for comparison, this is pleasing because
the generalized subset is closely semantically related
to implication. (In fact some books write implication with
the subset character.) It vaguely feels like it's pointing
the wrong way, though. And what's the reverse? <=?
That's the usual programming language scalar less-than-
or-equal. So maybe it's "=<"? I dunno. Maybe it should
be << and >>. And then you still have the = problem,
and the precedence thereof.
I'm not even absolutely sure there are two different
equalities, though. Maybe there is just the one equality,
and we define the relational comparison with it. Vice versa
also works. But we need *something* besides just the
two lattice operators or we can't compare relations.
Quote:
|
2. Explicit column variables. Having two sorts of symbols -- realtion and attribute variables -- makes RL expressions less pretty. |
they should be syntactically distinct? Because I can recall
you writing similar expressions, but with a different syntax.
X join {(x, y) | x = y}
I would write:
X & x = y
and you might write
X /\ `x=y`
Yes, there is some concern about relation variables
and attribute names appearing at the same lexical
level in expressions, but my tendency is to believe the
brevity is worth the risk. Attributes and variables are
all declared ahead of time, after all, so there is
no direct source of ambiguity. The one real concern
I have is with code changing over time. What if a
name that appears free in an expression, and is
thereby classified as an attribute name (as y is
above) is, in a later version of a file, used at a
higher lexical scope, changing the meaning of
existing expressions? That seems like a bad thing,
so it might be required to declare attributes before
use that would otherwise appear free.
Marshall
#8
| |||
| |||
|
|
Marshall wrote: Brass tacks: X(x) -- the domain R(a, b) -- the relation X & (x=a) & (x=b) => R X is a relation with one attribute, x. R is a relation with attributes a and b, taken from the members of X The phrase "(x=a)" denotes the infinite relation of attributes a and x where a = x. In set builder notation: {(x, a) | x in X and x = a} "&" is natural join. So X & (x=a) joins X with (x=a), creating a new relation with attributes x and a. X & (x=a) & (x=b) does the same thing, so now we have {(x, a, b) | x in X and x = a and x = b} "=>" is the generalized subset operator. It takes two relation operands, and evaluates to true if the left operand has a superset of the attributes, and a subset of the elements of the right operand. I suspect only 3 people in the world are comfortable with this notation:-) |
Quote:
|
It is imperfect for at least two reasons: 1. Equality relation, is it some kind of constant in the RA? Also the "=" symbol in the (a=b) conflicts with the equality among relations. Two levels of equality is something people never dealt before? |
for someone as deep into parsing as you. What is worse,
I write relational equality as if it had precedence lower than
&, and the other equality as if it had higher precedence.
In general, I have been trying to completely separate the
relational operators and the scalar operators. Eliminating
booleans in favor of DEE and DUM has made this easier,
but we still have the problem of comparison and equality.
If we use => for comparison, this is pleasing because
the generalized subset is closely semantically related
to implication. (In fact some books write implication with
the subset character.) It vaguely feels like it's pointing
the wrong way, though. And what's the reverse? <=?
That's the usual programming language scalar less-than-
or-equal. So maybe it's "=<"? I dunno. Maybe it should
be << and >>. And then you still have the = problem,
and the precedence thereof.
I'm not even absolutely sure there are two different
equalities, though. Maybe there is just the one equality,
and we define the relational comparison with it. Vice versa
also works. But we need *something* besides just the
two lattice operators or we can't compare relations.
Quote:
|
2. Explicit column variables. Having two sorts of symbols -- realtion and attribute variables -- makes RL expressions less pretty. |
they should be syntactically distinct? Because I can recall
you writing similar expressions, but with a different syntax.
X join {(x, y) | x = y}
I would write:
X & x = y
and you might write
X /\ `x=y`
Yes, there is some concern about relation variables
and attribute names appearing at the same lexical
level in expressions, but my tendency is to believe the
brevity is worth the risk. Attributes and variables are
all declared ahead of time, after all, so there is
no direct source of ambiguity. The one real concern
I have is with code changing over time. What if a
name that appears free in an expression, and is
thereby classified as an attribute name (as y is
above) is, in a later version of a file, used at a
higher lexical scope, changing the meaning of
existing expressions? That seems like a bad thing,
so it might be required to declare attributes before
use that would otherwise appear free.
Marshall
#9
| |||
| |||
|
|
Marshall wrote: Brass tacks: X(x) -- the domain R(a, b) -- the relation X & (x=a) & (x=b) => R X is a relation with one attribute, x. R is a relation with attributes a and b, taken from the members of X The phrase "(x=a)" denotes the infinite relation of attributes a and x where a = x. In set builder notation: {(x, a) | x in X and x = a} "&" is natural join. So X & (x=a) joins X with (x=a), creating a new relation with attributes x and a. X & (x=a) & (x=b) does the same thing, so now we have {(x, a, b) | x in X and x = a and x = b} "=>" is the generalized subset operator. It takes two relation operands, and evaluates to true if the left operand has a superset of the attributes, and a subset of the elements of the right operand. I suspect only 3 people in the world are comfortable with this notation:-) |
Quote:
|
It is imperfect for at least two reasons: 1. Equality relation, is it some kind of constant in the RA? Also the "=" symbol in the (a=b) conflicts with the equality among relations. Two levels of equality is something people never dealt before? |
for someone as deep into parsing as you. What is worse,
I write relational equality as if it had precedence lower than
&, and the other equality as if it had higher precedence.
In general, I have been trying to completely separate the
relational operators and the scalar operators. Eliminating
booleans in favor of DEE and DUM has made this easier,
but we still have the problem of comparison and equality.
If we use => for comparison, this is pleasing because
the generalized subset is closely semantically related
to implication. (In fact some books write implication with
the subset character.) It vaguely feels like it's pointing
the wrong way, though. And what's the reverse? <=?
That's the usual programming language scalar less-than-
or-equal. So maybe it's "=<"? I dunno. Maybe it should
be << and >>. And then you still have the = problem,
and the precedence thereof.
I'm not even absolutely sure there are two different
equalities, though. Maybe there is just the one equality,
and we define the relational comparison with it. Vice versa
also works. But we need *something* besides just the
two lattice operators or we can't compare relations.
Quote:
|
2. Explicit column variables. Having two sorts of symbols -- realtion and attribute variables -- makes RL expressions less pretty. |
they should be syntactically distinct? Because I can recall
you writing similar expressions, but with a different syntax.
X join {(x, y) | x = y}
I would write:
X & x = y
and you might write
X /\ `x=y`
Yes, there is some concern about relation variables
and attribute names appearing at the same lexical
level in expressions, but my tendency is to believe the
brevity is worth the risk. Attributes and variables are
all declared ahead of time, after all, so there is
no direct source of ambiguity. The one real concern
I have is with code changing over time. What if a
name that appears free in an expression, and is
thereby classified as an attribute name (as y is
above) is, in a later version of a file, used at a
higher lexical scope, changing the meaning of
existing expressions? That seems like a bad thing,
so it might be required to declare attributes before
use that would otherwise appear free.
Marshall
#10
| |||
| |||
|
|
I'm not even absolutely sure there are two different equalities, though. Maybe there is just the one equality, and we define the relational comparison with it. Vice versa also works. But we need *something* besides just the two lattice operators or we can't compare relations. |
have just one more constant: Universal Equality Relation (denoted as
E)? Then x=y is defined E projected to attributes x and y. What abouy
incompatible domains, though? If x and z are incompatible, we can't
define E projected to x,z as empty. We have to (somewhat counter
intuitively) to define x=z as a cartesian product of the domains!
So we have 5 constants: 00, 01, 10, 11 and E -- sounds too many.
Although, 10 and 01 are the least intersting elements of RL, so it is
really only 00, 11 and E that matter.
Quote:
|
Yes, there is some concern about relation variables and attribute names appearing at the same lexical level in expressions, but my tendency is to believe the brevity is worth the risk... |
RL expressions in completely attribute free fascion. Whenever there is
an expression and there is a relation with some specific constraints
(e.g. having attribute x, or being empty), then it could be rewritten
in more general way without these constraints. In principle generality
should lead to simplicity....
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.