David BL wrote:
....
Without getting into whether "recursive RVAs" are actually possible,
whenever I've written programs I've always been struck by the old wisdom
that certain structures make the mental explanation of the job easier.
But regarding theory, one question I have about such a structure is
whether it can logically stand for a reasonable predicate. A simpler
structure I've brought up before is this:


R{a int, b typeof(R)}


(Here, "typeof" is a language gizmo that stands for a type that is the
same type as R's type.)


If R's extension can be loosely pictured like so, where the string "a b"
stands for a conventional heading, R has one tuple and the "first" b has
one tuple and the second "b" has no tuples:


R
a b
a b
1 2 {},


I might refer to the value 2 which is of type int (as opposed to the
value (2 {}) which is a value of a relation) with another gizmo such as
"b.a". A predicate for this might be "a plus 1 equals b.a".


To my way of thinking, no matter what predicate or relation we decide
stands between a and a.b, there must be another predicate that involves
a and b, say for example's sake, "b is the set of tuples that have 'a'
values that are numerically larger than the value of a".


One problem I have with talking about RVA's for this example is that I
can't get very far with a notation that might need to look something
like a.(b.a(b.a(b.a(b.a)))) when writing a query to find out if the
number 5 has such a tuple, in other words "is the integer 5 greater than
the integer 1?".


The thought that keeps recurring (ha, ha) to me is that if any of the
above is reasonable I would need a different notion of projection than
the conventional one, one that allows me to to see a relation that
involves the "second" predicate. Graphically, let me write it like so:


P
a b.a
1 2
1 3
1 4
1 5
2 3
2 4
etc.

P would be easy to query (ie., not cumbersome) using conventional RM
theory. It makes me wonder if there is a way to see conventional
non-recursive relations as being a special case of recursive ones.


Eg., as far as syntax goes, I can't think why I shouldn't be able to
express P as "R{a,b.a}". This is different from "R{a,b}" which
expresses identity in the conventional way, ie., "R is equal to R{a,b}"
whereas in P, "a" ranges over all "b.a's" but not all "b.a's" range over
all "a's". In terms of practical results, I suppose the "b.a" notation
is not much different from introducing a "tclose" operator. For some
reason I can't explain very well, I find it more appealing to express
structure than to express procedure.


Sometimes I also wonder whether conventional projection is too
simplistic even for non-recursive relations. There is always an
unwritten second operand, the complement of the attributes that name the
chosen projection. When people like Fabian P talk about "R-tables", it
seems to me that sometimes they don't want that second operand to always
be the same complement.


(Maybe part of the reason is that the RM puts so much emphasis on the
logical structure of data (which seems under-explored and widely ignored
to me, at least in the mainstream press, eg., hardly anybody writes
about the logical use of material implication for certain kinds of
constraints.)


Just trying to keep things going here ...

David BL wrote:
....
Without getting into whether "recursive RVAs" are actually possible,
whenever I've written programs I've always been struck by the old wisdom
that certain structures make the mental explanation of the job easier.
But regarding theory, one question I have about such a structure is
whether it can logically stand for a reasonable predicate. A simpler
structure I've brought up before is this:


R{a int, b typeof(R)}


(Here, "typeof" is a language gizmo that stands for a type that is the
same type as R's type.)


If R's extension can be loosely pictured like so, where the string "a b"
stands for a conventional heading, R has one tuple and the "first" b has
one tuple and the second "b" has no tuples:


R
a b
a b
1 2 {},


I might refer to the value 2 which is of type int (as opposed to the
value (2 {}) which is a value of a relation) with another gizmo such as
"b.a". A predicate for this might be "a plus 1 equals b.a".


To my way of thinking, no matter what predicate or relation we decide
stands between a and a.b, there must be another predicate that involves
a and b, say for example's sake, "b is the set of tuples that have 'a'
values that are numerically larger than the value of a".


One problem I have with talking about RVA's for this example is that I
can't get very far with a notation that might need to look something
like a.(b.a(b.a(b.a(b.a)))) when writing a query to find out if the
number 5 has such a tuple, in other words "is the integer 5 greater than
the integer 1?".


The thought that keeps recurring (ha, ha) to me is that if any of the
above is reasonable I would need a different notion of projection than
the conventional one, one that allows me to to see a relation that
involves the "second" predicate. Graphically, let me write it like so:


P
a b.a
1 2
1 3
1 4
1 5
2 3
2 4
etc.

P would be easy to query (ie., not cumbersome) using conventional RM
theory. It makes me wonder if there is a way to see conventional
non-recursive relations as being a special case of recursive ones.


Eg., as far as syntax goes, I can't think why I shouldn't be able to
express P as "R{a,b.a}". This is different from "R{a,b}" which
expresses identity in the conventional way, ie., "R is equal to R{a,b}"
whereas in P, "a" ranges over all "b.a's" but not all "b.a's" range over
all "a's". In terms of practical results, I suppose the "b.a" notation
is not much different from introducing a "tclose" operator. For some
reason I can't explain very well, I find it more appealing to express
structure than to express procedure.


Sometimes I also wonder whether conventional projection is too
simplistic even for non-recursive relations. There is always an
unwritten second operand, the complement of the attributes that name the
chosen projection. When people like Fabian P talk about "R-tables", it
seems to me that sometimes they don't want that second operand to always
be the same complement.


(Maybe part of the reason is that the RM puts so much emphasis on the
logical structure of data (which seems under-explored and widely ignored
to me, at least in the mainstream press, eg., hardly anybody writes
about the logical use of material implication for certain kinds of
constraints.)


Just trying to keep things going here ...

David BL wrote:
....
Without getting into whether "recursive RVAs" are actually possible,
whenever I've written programs I've always been struck by the old wisdom
that certain structures make the mental explanation of the job easier.
But regarding theory, one question I have about such a structure is
whether it can logically stand for a reasonable predicate. A simpler
structure I've brought up before is this:


R{a int, b typeof(R)}


(Here, "typeof" is a language gizmo that stands for a type that is the
same type as R's type.)


If R's extension can be loosely pictured like so, where the string "a b"
stands for a conventional heading, R has one tuple and the "first" b has
one tuple and the second "b" has no tuples:


R
a b
a b
1 2 {},


I might refer to the value 2 which is of type int (as opposed to the
value (2 {}) which is a value of a relation) with another gizmo such as
"b.a". A predicate for this might be "a plus 1 equals b.a".


To my way of thinking, no matter what predicate or relation we decide
stands between a and a.b, there must be another predicate that involves
a and b, say for example's sake, "b is the set of tuples that have 'a'
values that are numerically larger than the value of a".


One problem I have with talking about RVA's for this example is that I
can't get very far with a notation that might need to look something
like a.(b.a(b.a(b.a(b.a)))) when writing a query to find out if the
number 5 has such a tuple, in other words "is the integer 5 greater than
the integer 1?".


The thought that keeps recurring (ha, ha) to me is that if any of the
above is reasonable I would need a different notion of projection than
the conventional one, one that allows me to to see a relation that
involves the "second" predicate. Graphically, let me write it like so:


P
a b.a
1 2
1 3
1 4
1 5
2 3
2 4
etc.

P would be easy to query (ie., not cumbersome) using conventional RM
theory. It makes me wonder if there is a way to see conventional
non-recursive relations as being a special case of recursive ones.


Eg., as far as syntax goes, I can't think why I shouldn't be able to
express P as "R{a,b.a}". This is different from "R{a,b}" which
expresses identity in the conventional way, ie., "R is equal to R{a,b}"
whereas in P, "a" ranges over all "b.a's" but not all "b.a's" range over
all "a's". In terms of practical results, I suppose the "b.a" notation
is not much different from introducing a "tclose" operator. For some
reason I can't explain very well, I find it more appealing to express
structure than to express procedure.


Sometimes I also wonder whether conventional projection is too
simplistic even for non-recursive relations. There is always an
unwritten second operand, the complement of the attributes that name the
chosen projection. When people like Fabian P talk about "R-tables", it
seems to me that sometimes they don't want that second operand to always
be the same complement.


(Maybe part of the reason is that the RM puts so much emphasis on the
logical structure of data (which seems under-explored and widely ignored
to me, at least in the mainstream press, eg., hardly anybody writes
about the logical use of material implication for certain kinds of
constraints.)


Just trying to keep things going here ...

David BL wrote:
....
Without getting into whether "recursive RVAs" are actually possible,
whenever I've written programs I've always been struck by the old wisdom
that certain structures make the mental explanation of the job easier.
But regarding theory, one question I have about such a structure is
whether it can logically stand for a reasonable predicate. A simpler
structure I've brought up before is this:


R{a int, b typeof(R)}


(Here, "typeof" is a language gizmo that stands for a type that is the
same type as R's type.)


If R's extension can be loosely pictured like so, where the string "a b"
stands for a conventional heading, R has one tuple and the "first" b has
one tuple and the second "b" has no tuples:


R
a b
a b
1 2 {},


I might refer to the value 2 which is of type int (as opposed to the
value (2 {}) which is a value of a relation) with another gizmo such as
"b.a". A predicate for this might be "a plus 1 equals b.a".


To my way of thinking, no matter what predicate or relation we decide
stands between a and a.b, there must be another predicate that involves
a and b, say for example's sake, "b is the set of tuples that have 'a'
values that are numerically larger than the value of a".


One problem I have with talking about RVA's for this example is that I
can't get very far with a notation that might need to look something
like a.(b.a(b.a(b.a(b.a)))) when writing a query to find out if the
number 5 has such a tuple, in other words "is the integer 5 greater than
the integer 1?".


The thought that keeps recurring (ha, ha) to me is that if any of the
above is reasonable I would need a different notion of projection than
the conventional one, one that allows me to to see a relation that
involves the "second" predicate. Graphically, let me write it like so:


P
a b.a
1 2
1 3
1 4
1 5
2 3
2 4
etc.

P would be easy to query (ie., not cumbersome) using conventional RM
theory. It makes me wonder if there is a way to see conventional
non-recursive relations as being a special case of recursive ones.


Eg., as far as syntax goes, I can't think why I shouldn't be able to
express P as "R{a,b.a}". This is different from "R{a,b}" which
expresses identity in the conventional way, ie., "R is equal to R{a,b}"
whereas in P, "a" ranges over all "b.a's" but not all "b.a's" range over
all "a's". In terms of practical results, I suppose the "b.a" notation
is not much different from introducing a "tclose" operator. For some
reason I can't explain very well, I find it more appealing to express
structure than to express procedure.


Sometimes I also wonder whether conventional projection is too
simplistic even for non-recursive relations. There is always an
unwritten second operand, the complement of the attributes that name the
chosen projection. When people like Fabian P talk about "R-tables", it
seems to me that sometimes they don't want that second operand to always
be the same complement.


(Maybe part of the reason is that the RM puts so much emphasis on the
logical structure of data (which seems under-explored and widely ignored
to me, at least in the mainstream press, eg., hardly anybody writes
about the logical use of material implication for certain kinds of
constraints.)


Just trying to keep things going here ...

David BL wrote:
....
Without getting into whether "recursive RVAs" are actually possible,
whenever I've written programs I've always been struck by the old wisdom
that certain structures make the mental explanation of the job easier.
But regarding theory, one question I have about such a structure is
whether it can logically stand for a reasonable predicate. A simpler
structure I've brought up before is this:


R{a int, b typeof(R)}


(Here, "typeof" is a language gizmo that stands for a type that is the
same type as R's type.)


If R's extension can be loosely pictured like so, where the string "a b"
stands for a conventional heading, R has one tuple and the "first" b has
one tuple and the second "b" has no tuples:


R
a b
a b
1 2 {},


I might refer to the value 2 which is of type int (as opposed to the
value (2 {}) which is a value of a relation) with another gizmo such as
"b.a". A predicate for this might be "a plus 1 equals b.a".


To my way of thinking, no matter what predicate or relation we decide
stands between a and a.b, there must be another predicate that involves
a and b, say for example's sake, "b is the set of tuples that have 'a'
values that are numerically larger than the value of a".


One problem I have with talking about RVA's for this example is that I
can't get very far with a notation that might need to look something
like a.(b.a(b.a(b.a(b.a)))) when writing a query to find out if the
number 5 has such a tuple, in other words "is the integer 5 greater than
the integer 1?".


The thought that keeps recurring (ha, ha) to me is that if any of the
above is reasonable I would need a different notion of projection than
the conventional one, one that allows me to to see a relation that
involves the "second" predicate. Graphically, let me write it like so:


P
a b.a
1 2
1 3
1 4
1 5
2 3
2 4
etc.

P would be easy to query (ie., not cumbersome) using conventional RM
theory. It makes me wonder if there is a way to see conventional
non-recursive relations as being a special case of recursive ones.


Eg., as far as syntax goes, I can't think why I shouldn't be able to
express P as "R{a,b.a}". This is different from "R{a,b}" which
expresses identity in the conventional way, ie., "R is equal to R{a,b}"
whereas in P, "a" ranges over all "b.a's" but not all "b.a's" range over
all "a's". In terms of practical results, I suppose the "b.a" notation
is not much different from introducing a "tclose" operator. For some
reason I can't explain very well, I find it more appealing to express
structure than to express procedure.


Sometimes I also wonder whether conventional projection is too
simplistic even for non-recursive relations. There is always an
unwritten second operand, the complement of the attributes that name the
chosen projection. When people like Fabian P talk about "R-tables", it
seems to me that sometimes they don't want that second operand to always
be the same complement.


(Maybe part of the reason is that the RM puts so much emphasis on the
logical structure of data (which seems under-explored and widely ignored
to me, at least in the mainstream press, eg., hardly anybody writes
about the logical use of material implication for certain kinds of
constraints.)


Just trying to keep things going here ...

David BL wrote:
....
Without getting into whether "recursive RVAs" are actually possible,
whenever I've written programs I've always been struck by the old wisdom
that certain structures make the mental explanation of the job easier.
But regarding theory, one question I have about such a structure is
whether it can logically stand for a reasonable predicate. A simpler
structure I've brought up before is this:


R{a int, b typeof(R)}


(Here, "typeof" is a language gizmo that stands for a type that is the
same type as R's type.)


If R's extension can be loosely pictured like so, where the string "a b"
stands for a conventional heading, R has one tuple and the "first" b has
one tuple and the second "b" has no tuples:


R
a b
a b
1 2 {},


I might refer to the value 2 which is of type int (as opposed to the
value (2 {}) which is a value of a relation) with another gizmo such as
"b.a". A predicate for this might be "a plus 1 equals b.a".


To my way of thinking, no matter what predicate or relation we decide
stands between a and a.b, there must be another predicate that involves
a and b, say for example's sake, "b is the set of tuples that have 'a'
values that are numerically larger than the value of a".


One problem I have with talking about RVA's for this example is that I
can't get very far with a notation that might need to look something
like a.(b.a(b.a(b.a(b.a)))) when writing a query to find out if the
number 5 has such a tuple, in other words "is the integer 5 greater than
the integer 1?".


The thought that keeps recurring (ha, ha) to me is that if any of the
above is reasonable I would need a different notion of projection than
the conventional one, one that allows me to to see a relation that
involves the "second" predicate. Graphically, let me write it like so:


P
a b.a
1 2
1 3
1 4
1 5
2 3
2 4
etc.

P would be easy to query (ie., not cumbersome) using conventional RM
theory. It makes me wonder if there is a way to see conventional
non-recursive relations as being a special case of recursive ones.


Eg., as far as syntax goes, I can't think why I shouldn't be able to
express P as "R{a,b.a}". This is different from "R{a,b}" which
expresses identity in the conventional way, ie., "R is equal to R{a,b}"
whereas in P, "a" ranges over all "b.a's" but not all "b.a's" range over
all "a's". In terms of practical results, I suppose the "b.a" notation
is not much different from introducing a "tclose" operator. For some
reason I can't explain very well, I find it more appealing to express
structure than to express procedure.


Sometimes I also wonder whether conventional projection is too
simplistic even for non-recursive relations. There is always an
unwritten second operand, the complement of the attributes that name the
chosen projection. When people like Fabian P talk about "R-tables", it
seems to me that sometimes they don't want that second operand to always
be the same complement.


(Maybe part of the reason is that the RM puts so much emphasis on the
logical structure of data (which seems under-explored and widely ignored
to me, at least in the mainstream press, eg., hardly anybody writes
about the logical use of material implication for certain kinds of
constraints.)


Just trying to keep things going here ...

David BL wrote:
....
Without getting into whether "recursive RVAs" are actually possible,
whenever I've written programs I've always been struck by the old wisdom
that certain structures make the mental explanation of the job easier.
But regarding theory, one question I have about such a structure is
whether it can logically stand for a reasonable predicate. A simpler
structure I've brought up before is this:


R{a int, b typeof(R)}


(Here, "typeof" is a language gizmo that stands for a type that is the
same type as R's type.)


If R's extension can be loosely pictured like so, where the string "a b"
stands for a conventional heading, R has one tuple and the "first" b has
one tuple and the second "b" has no tuples:


R
a b
a b
1 2 {},


I might refer to the value 2 which is of type int (as opposed to the
value (2 {}) which is a value of a relation) with another gizmo such as
"b.a". A predicate for this might be "a plus 1 equals b.a".


To my way of thinking, no matter what predicate or relation we decide
stands between a and a.b, there must be another predicate that involves
a and b, say for example's sake, "b is the set of tuples that have 'a'
values that are numerically larger than the value of a".


One problem I have with talking about RVA's for this example is that I
can't get very far with a notation that might need to look something
like a.(b.a(b.a(b.a(b.a)))) when writing a query to find out if the
number 5 has such a tuple, in other words "is the integer 5 greater than
the integer 1?".


The thought that keeps recurring (ha, ha) to me is that if any of the
above is reasonable I would need a different notion of projection than
the conventional one, one that allows me to to see a relation that
involves the "second" predicate. Graphically, let me write it like so:


P
a b.a
1 2
1 3
1 4
1 5
2 3
2 4
etc.

P would be easy to query (ie., not cumbersome) using conventional RM
theory. It makes me wonder if there is a way to see conventional
non-recursive relations as being a special case of recursive ones.


Eg., as far as syntax goes, I can't think why I shouldn't be able to
express P as "R{a,b.a}". This is different from "R{a,b}" which
expresses identity in the conventional way, ie., "R is equal to R{a,b}"
whereas in P, "a" ranges over all "b.a's" but not all "b.a's" range over
all "a's". In terms of practical results, I suppose the "b.a" notation
is not much different from introducing a "tclose" operator. For some
reason I can't explain very well, I find it more appealing to express
structure than to express procedure.


Sometimes I also wonder whether conventional projection is too
simplistic even for non-recursive relations. There is always an
unwritten second operand, the complement of the attributes that name the
chosen projection. When people like Fabian P talk about "R-tables", it
seems to me that sometimes they don't want that second operand to always
be the same complement.


(Maybe part of the reason is that the RM puts so much emphasis on the
logical structure of data (which seems under-explored and widely ignored
to me, at least in the mainstream press, eg., hardly anybody writes
about the logical use of material implication for certain kinds of
constraints.)


Just trying to keep things going here ...