TTM without tuples

#21 · April 13, 2021, 3:03 pm

Quote from Dave Voorhis on April 13, 2021, 3:03 pm

Quote from dandl on April 13, 2021, 1:59 pm

Quote from Dave Voorhis on April 13, 2021, 11:19 am

Quote from dandl on April 13, 2021, 10:44 am

Quote from AntC on April 13, 2021, 8:19 am

Quote from dandl on April 13, 2021, 4:11 am

So it's blindingly obvious that the whole of the RA in Andl or TD or any other TTM/D can proceed happily with no recourse to a tuple type.

Perhaps you'd be so good as to point out to those of us who are obviously blind, how what you say differs from mystical incantation. I can't comment on Andl of course, and "any other TTM/D" requires too much imagination for me. Let's stick to Tutorial D, and let's try to spell it in full with the approved formatting.

I don't see how Tutorial D would be expressively complete without tuple literals. (Possibly it might avoid tuple variables.) And those literals would have a type. How do I, for example, express DEE?

I do allow myself the thought that like the recent occupant of the White House, you're going to keep making more and more outrageous claims, to ensure you're always first item on Fox News. Then it might help you to know that I watch Fox News purely as a mechanism for letting off steam; not expecting to find anything true, logical or coherent. I don't need a second Fox News. And you're veering towards those web sites advocating for a flat earth.

I did actually spell it out, but for those were weren't paying attention it goes like this.

Remove the word TUPLE and every construct that depends on it.

Create a new selector for relations. See below for a suggestion, as per Andl. Or you might prefer a function that takes an array of scalar type, as per ARRAY.

Change ARRAY so it is an array of scalar type, where the component names are required to be a subset of the corresponding attribute names.

{{name:text,age:number}
('Smith', 17),
('Jones', 35),
('Frankenstein', 199)
}

The literal for DEE might be (as per Andl): {{}} or RELATION().

And before you ask, DUM might be {{}{}} or RELATION(()).

It just isn't that hard. I'm sure you could figure it out.

Incidentally, I think you would find the Haskell implementation way simpler without the tuples. Forget nasty records, you don't need them.

That's just syntactic elision. Semantically, it's still tuples.

I don't know what you thought I was proposing, but the above demonstrates beyond question that it is possible to remove the tuple type from TTM. As I said.

You've removed a syntactic construct but not the underlying semantics.

Yes, relations are defined in terms of tuples, but tuple values and types do not appear in D. That's all.

The problem of static nominal vs structural typing doesn't go away by syntactically eliding tuples. It's still present for relations.

No it isn't. Show me where.

In whatever popular programming language you like, declare a relation-valued variable with heading (using Tutorial D syntax to avoid ambiguity; alter as needed to suit your choice of language) {x int, y char}. Persistence is not necessary.

Assign the variable a relation literal (using Tutorial D again; alter to suit) REL {TUP {x 1, y 'zot'}}. It should compile.

Attempt to assign the variable a relation literal REL {TUP {y 'zot', x 1}}. It should compile.

Attempt to assign the variable a relation literal REL {TUP {x 'zot', y 1}}. It should fail to compile due to a type mismatch.

Attempt to assign the variable a relation literal REL {TUP {x 1, y 'zot'}, TUP {x 'zot', y 1}}. It should fail to compile due to a type mismatch, either per the second tuple not matching the heading of the first or (if we assume the IM) for an attempt to assign REL {x ALPHA, y ALPHA} {...} to a variable of type REL {x int, y char}.

The syntax can be whatever you like. The compiler-enforced semantics -- particularly the static type checks -- should be preserved.

Quote from dandl on April 13, 2021, 1:59 pm

Quote from Dave Voorhis on April 13, 2021, 11:19 am

Quote from dandl on April 13, 2021, 10:44 am

Quote from AntC on April 13, 2021, 8:19 am

Quote from dandl on April 13, 2021, 4:11 am

So it's blindingly obvious that the whole of the RA in Andl or TD or any other TTM/D can proceed happily with no recourse to a tuple type.

Perhaps you'd be so good as to point out to those of us who are obviously blind, how what you say differs from mystical incantation. I can't comment on Andl of course, and "any other TTM/D" requires too much imagination for me. Let's stick to Tutorial D, and let's try to spell it in full with the approved formatting.

I don't see how Tutorial D would be expressively complete without tuple literals. (Possibly it might avoid tuple variables.) And those literals would have a type. How do I, for example, express DEE?

I do allow myself the thought that like the recent occupant of the White House, you're going to keep making more and more outrageous claims, to ensure you're always first item on Fox News. Then it might help you to know that I watch Fox News purely as a mechanism for letting off steam; not expecting to find anything true, logical or coherent. I don't need a second Fox News. And you're veering towards those web sites advocating for a flat earth.

I did actually spell it out, but for those were weren't paying attention it goes like this.

Remove the word TUPLE and every construct that depends on it.

Create a new selector for relations. See below for a suggestion, as per Andl. Or you might prefer a function that takes an array of scalar type, as per ARRAY.

Change ARRAY so it is an array of scalar type, where the component names are required to be a subset of the corresponding attribute names.

{{name:text,age:number}
('Smith', 17),
('Jones', 35),
('Frankenstein', 199)
}

The literal for DEE might be (as per Andl): {{}} or RELATION().

And before you ask, DUM might be {{}{}} or RELATION(()).

It just isn't that hard. I'm sure you could figure it out.

Incidentally, I think you would find the Haskell implementation way simpler without the tuples. Forget nasty records, you don't need them.

That's just syntactic elision. Semantically, it's still tuples.

I don't know what you thought I was proposing, but the above demonstrates beyond question that it is possible to remove the tuple type from TTM. As I said.

You've removed a syntactic construct but not the underlying semantics.

Yes, relations are defined in terms of tuples, but tuple values and types do not appear in D. That's all.

The problem of static nominal vs structural typing doesn't go away by syntactically eliding tuples. It's still present for relations.

No it isn't. Show me where.

In whatever popular programming language you like, declare a relation-valued variable with heading (using Tutorial D syntax to avoid ambiguity; alter as needed to suit your choice of language) {x int, y char}. Persistence is not necessary.

Assign the variable a relation literal (using Tutorial D again; alter to suit) REL {TUP {x 1, y 'zot'}}. It should compile.

Attempt to assign the variable a relation literal REL {TUP {y 'zot', x 1}}. It should compile.

Attempt to assign the variable a relation literal REL {TUP {x 'zot', y 1}}. It should fail to compile due to a type mismatch.

Attempt to assign the variable a relation literal REL {TUP {x 1, y 'zot'}, TUP {x 'zot', y 1}}. It should fail to compile due to a type mismatch, either per the second tuple not matching the heading of the first or (if we assume the IM) for an attempt to assign REL {x ALPHA, y ALPHA} {...} to a variable of type REL {x int, y char}.

The syntax can be whatever you like. The compiler-enforced semantics -- particularly the static type checks -- should be preserved.

I'm the forum administrator and lead developer of Rel. Email me at dave@armchair.mb.ca with the Subject 'TTM Forum'. Download Rel from https://reldb.org

#22 · April 13, 2021, 4:17 pm

Quote from AntC on April 13, 2021, 8:19 am

Quote from dandl on April 13, 2021, 4:11 am

So it's blindingly obvious that the whole of the RA in Andl or TD or any other TTM/D can proceed happily with no recourse to a tuple type.

I don't see how Tutorial D would be expressively complete without tuple literals. (Possibly it might avoid tuple variables.) And those literals would have a type. How do I, for example, express DEE?

Same way the first four published versions of SIRA_PRISE managed to do without a full-blown and fully-supported tuple type "as a type in its own right". Yes you do need ***some*** kind of syntax to specify what the tuple values are (or what the tuple value selecting expressions are) ***inside*** a relation value selector, but that's the ***only*** spot in the language where that holds. So in V1.4 [and before, obviously], the syntactical form "TUPLE(...)" could appear only inside an appearance of [the syntactical form of "BODY(...)" -either explicit or implied- appearing inside the appearance of] the syntactical form "RELATION(...)", and the grammar said so much, and in V1.5, that same appearance of the syntactical form "TUPLE(...)" could suddenly match the grammar rule that said that "all value selectors are introduced by the type name" (***), and the very same construct could now also appear outside an appearance of the syntactical form "RELATION(...)". I have no doubt the V1.4 approach was less desirable than the V1.5 one, because unquestionably at odds with at least ***some*** kind of "purist" rule of language design, but it ***never*** caused the system overall to not do anything it was supposed to do.

In particular, it satisfied all the requirements stated in Dave's foregoing post.

(***) this is a shortcut description that deliberately fails to make the distinction between [the invocation name for] a type and [for] a type generator. It's not material to the point being made.

#23 · April 14, 2021, 12:17 am

Quote from dandl on April 14, 2021, 12:17 am

Quote from Erwin on April 13, 2021, 4:17 pm

Quote from AntC on April 13, 2021, 8:19 am

Quote from dandl on April 13, 2021, 4:11 am

So it's blindingly obvious that the whole of the RA in Andl or TD or any other TTM/D can proceed happily with no recourse to a tuple type.

I don't see how Tutorial D would be expressively complete without tuple literals. (Possibly it might avoid tuple variables.) And those literals would have a type. How do I, for example, express DEE?

Same way the first four published versions of SIRA_PRISE managed to do without a full-blown and fully-supported tuple type "as a type in its own right". Yes you do need ***some*** kind of syntax to specify what the tuple values are (or what the tuple value selecting expressions are) ***inside*** a relation value selector, but that's the ***only*** spot in the language where that holds. So in V1.4 [and before, obviously], the syntactical form "TUPLE(...)" could appear only inside an appearance of [the syntactical form of "BODY(...)" -either explicit or implied- appearing inside the appearance of] the syntactical form "RELATION(...)", and the grammar said so much, and in V1.5, that same appearance of the syntactical form "TUPLE(...)" could suddenly match the grammar rule that said that "all value selectors are introduced by the type name" (***), and the very same construct could now also appear outside an appearance of the syntactical form "RELATION(...)". I have no doubt the V1.4 approach was less desirable than the V1.5 one, because unquestionably at odds with at least ***some*** kind of "purist" rule of language design, but it ***never*** caused the system overall to not do anything it was supposed to do.

In particular, it satisfied all the requirements stated in Dave's foregoing post.

(***) this is a shortcut description that deliberately fails to make the distinction between [the invocation name for] a type and [for] a type generator. It's not material to the point being made.

Just so. Nothing to add.

Quote from Erwin on April 13, 2021, 4:17 pm

Quote from AntC on April 13, 2021, 8:19 am

Quote from dandl on April 13, 2021, 4:11 am

So it's blindingly obvious that the whole of the RA in Andl or TD or any other TTM/D can proceed happily with no recourse to a tuple type.

I don't see how Tutorial D would be expressively complete without tuple literals. (Possibly it might avoid tuple variables.) And those literals would have a type. How do I, for example, express DEE?

Same way the first four published versions of SIRA_PRISE managed to do without a full-blown and fully-supported tuple type "as a type in its own right". Yes you do need ***some*** kind of syntax to specify what the tuple values are (or what the tuple value selecting expressions are) ***inside*** a relation value selector, but that's the ***only*** spot in the language where that holds. So in V1.4 [and before, obviously], the syntactical form "TUPLE(...)" could appear only inside an appearance of [the syntactical form of "BODY(...)" -either explicit or implied- appearing inside the appearance of] the syntactical form "RELATION(...)", and the grammar said so much, and in V1.5, that same appearance of the syntactical form "TUPLE(...)" could suddenly match the grammar rule that said that "all value selectors are introduced by the type name" (***), and the very same construct could now also appear outside an appearance of the syntactical form "RELATION(...)". I have no doubt the V1.4 approach was less desirable than the V1.5 one, because unquestionably at odds with at least ***some*** kind of "purist" rule of language design, but it ***never*** caused the system overall to not do anything it was supposed to do.

In particular, it satisfied all the requirements stated in Dave's foregoing post.

(***) this is a shortcut description that deliberately fails to make the distinction between [the invocation name for] a type and [for] a type generator. It's not material to the point being made.

Just so. Nothing to add.

Andl - A New Database Language - andl.org

#24 · April 14, 2021, 12:22 am

The problem of static nominal vs structural typing doesn't go away by syntactically eliding tuples. It's still present for relations.

No it isn't. Show me where.

In whatever popular programming language you like, declare a relation-valued variable with heading (using Tutorial D syntax to avoid ambiguity; alter as needed to suit your choice of language) {x int, y char}. Persistence is not necessary.

Assign the variable a relation literal (using Tutorial D again; alter to suit) REL {TUP {x 1, y 'zot'}}. It should compile.

Attempt to assign the variable a relation literal REL {TUP {y 'zot', x 1}}. It should compile.

Attempt to assign the variable a relation literal REL {TUP {x 'zot', y 1}}. It should fail to compile due to a type mismatch.

Attempt to assign the variable a relation literal REL {TUP {x 1, y 'zot'}, TUP {x 'zot', y 1}}. It should fail to compile due to a type mismatch, either per the second tuple not matching the heading of the first or (if we assume the IM) for an attempt to assign REL {x ALPHA, y ALPHA} {...} to a variable of type REL {x int, y char}.

The syntax can be whatever you like. The compiler-enforced semantics -- particularly the static type checks -- should be preserved.

Just so. I agree 100% with the semantics and the compiler behaviour.

On balance, in the context of TD, perhaps we could just use possrep-like syntax. The first two examples would be two different possrep types, but would both select the same relational value. You might want to call that 'structural', I just call it a smart compiler.

Andl - A New Database Language - andl.org

#25 · April 14, 2021, 3:35 am

Quote from dandl on April 14, 2021, 12:22 am

The problem of static nominal vs structural typing doesn't go away by syntactically eliding tuples. It's still present for relations.

No it isn't. Show me where.

In whatever popular programming language you like, declare a relation-valued variable with heading (using Tutorial D syntax to avoid ambiguity; alter as needed to suit your choice of language) {x int, y char}. Persistence is not necessary.

Assign the variable a relation literal (using Tutorial D again; alter to suit) REL {TUP {x 1, y 'zot'}}. It should compile.

Attempt to assign the variable a relation literal REL {TUP {y 'zot', x 1}}. It should compile.

Attempt to assign the variable a relation literal REL {TUP {x 'zot', y 1}}. It should fail to compile due to a type mismatch.

Attempt to assign the variable a relation literal REL {TUP {x 1, y 'zot'}, TUP {x 'zot', y 1}}. It should fail to compile due to a type mismatch, either per the second tuple not matching the heading of the first or (if we assume the IM) for an attempt to assign REL {x ALPHA, y ALPHA} {...} to a variable of type REL {x int, y char}.

The syntax can be whatever you like. The compiler-enforced semantics -- particularly the static type checks -- should be preserved.

Just so. I agree 100% with the semantics and the compiler behaviour.

On balance, in the context of TD, perhaps we could just use possrep-like syntax. The first two examples would be two different possrep types, but would both select the same relational value. You might want to call that 'structural', I just call it a smart compiler.

Which brings us back almost exactly to where we started, with the exact same typing problem. We didn't really gain very much since the same "smart compiler" could have worked out tuple typing in exactly the same way. One less detail without tuples, sure, but not "problem solved" since it is the "smart compiler" that is the problem.

#26 · April 14, 2021, 6:51 am

Quote from dandl on April 14, 2021, 12:22 am

The problem of static nominal vs structural typing doesn't go away by syntactically eliding tuples. It's still present for relations.

No it isn't. Show me where.

In whatever popular programming language you like, declare a relation-valued variable with heading (using Tutorial D syntax to avoid ambiguity; alter as needed to suit your choice of language) {x int, y char}. Persistence is not necessary.

Assign the variable a relation literal (using Tutorial D again; alter to suit) REL {TUP {x 1, y 'zot'}}. It should compile.

Attempt to assign the variable a relation literal REL {TUP {y 'zot', x 1}}. It should compile.

Attempt to assign the variable a relation literal REL {TUP {x 'zot', y 1}}. It should fail to compile due to a type mismatch.

Attempt to assign the variable a relation literal REL {TUP {x 1, y 'zot'}, TUP {x 'zot', y 1}}. It should fail to compile due to a type mismatch, either per the second tuple not matching the heading of the first or (if we assume the IM) for an attempt to assign REL {x ALPHA, y ALPHA} {...} to a variable of type REL {x int, y char}.

The syntax can be whatever you like. The compiler-enforced semantics -- particularly the static type checks -- should be preserved.

Just so. I agree 100% with the semantics and the compiler behaviour.

On balance, in the context of TD, perhaps we could just use possrep-like syntax. The first two examples would be two different possrep types, but would both select the same relational value. You might want to call that 'structural', I just call it a smart compiler.

Structural typing & nominal typing are the correct specific terms here. Learn them, and stop wasting our time with your attempts to lawyer your way around your own misunderstandings, and without invoking vague, meaningless, arm-wavey terms like "smart compiler."

I'm the forum administrator and lead developer of Rel. Email me at dave@armchair.mb.ca with the Subject 'TTM Forum'. Download Rel from https://reldb.org

#27 · April 14, 2021, 1:11 pm

Can dandl please remind me, what is the problem you are trying to solve?

To my mind, inclusion of "non-first-class" types in a language is a complication, not a simplification.

Btw, I saw somebody questioning whether a relation is a set of tuples or a set of attributes. It made me realise that I had been guilty of a bit of looseness when I wrote that it is a set of tuples.

A relation's body is a set of tuples.

A relation's heading is a set of attributes.

Did the questioner have some other notion of what an attribute is?

I dread the thought of changing TTM to avoid those definitions.

Also btw, a heading is a relation, an attribute is a tuple, and a tuple is a relation. True, but that way madness lies (as I believe CJD would have put it).

Sorry for butting in without reading all the correspondence.

Hugh

Coauthor of The Third Manifesto and related books.

#28 · April 14, 2021, 4:54 pm

Quote from Hugh on April 14, 2021, 1:11 pm

A relation's body is a set of tuples.

A relation's heading is a set of attributes.

Did the questioner have some other notion of what an attribute is?

I dread the thought of changing TTM to avoid those definitions.

Also btw, a heading is a relation, an attribute is a tuple, and a tuple is a relation. True, but that way madness lies (as I believe CJD would have put it).

Sorry for butting in without reading all the correspondence.

Hugh

As you have mentioned, a relation is not really a set, but a pair of header and body, each considered to be a set. Again, this traditional view has been challenged (or complemented) by the "columnar" database community, which considers a relation as a set of columns. There has to be conforming condition when "gluing" columns to construct relations of higher arity, of course, but the situation is similar to requiring tuples to match in conventional database theory.

I'll take one more step, and suggest that using "a set of" in database foundation is problematic. First of all, tuple- and column- perspectives clearly disagree what the set structure of a relation is. Second, mathematics field gradually shifted from emphasizing object's set structure to categorical view. Technically speaking, only some categories are structured sets. It would be interesting to formalize database relations in terms of objects and arrows, and I wonder if David Spivak's database category is the right one.

#29 · April 15, 2021, 12:26 am

Quote from Hugh on April 14, 2021, 1:11 pm

... Btw, I saw somebody questioning whether a relation is a set of tuples or a set of attributes. It made me realise that I had been guilty of a bit of looseness when I wrote that it is a set of tuples.

A relation's body is a set of tuples.

A relation's heading is a set of attributes.

Did the questioner have some other notion of what an attribute is?

I dread the thought of changing TTM to avoid those definitions.

Thanks Hugh, I think people said a number of things up-thread to try to emphasise how wrong was dandl's interpretation. There might have been quite a bit of "looseness". I take the definitions in TTM to be an abstraction. Some concrete implementation of a D might not have separately-identifiable components of a relation value (data structure) that exactly correspond.

OTOH your following remarks I'm finding hard to follow:

Also btw, a heading is a relation, an attribute is a tuple, and a tuple is a relation. True, but that way madness lies (as I believe CJD would have put it).

A heading ("is a relation" so) has a body and a heading? Then that heading must have a heading ... ad infinitum?

An attribute (you mean an <A, T, v> triple?) "is a tuple"? Then what is the heading of that tuple? Note that in the Tutorial D TUPLE{ ... } Selector, each element must include an A and a v, but the syntax doesn't require a T -- you can give one as a type annotation, but that's a ubiquitous feature, not specific to tuples.

A tuple "is a relation"? Then in Tutorial D I can denote a tuple value using the RELATION{ ... } Selector? And that would be different to a singleton relation? I don't follow.

Sorry for butting in without reading all the correspondence.

There has been a huge volume of correspondence, much of it repetitive and argumentative without shedding light. I'm not reading it all either. I'm not feeling any need to apologise.

#30 · April 15, 2021, 12:29 am

Quote from Hugh on April 14, 2021, 1:11 pm

Can dandl please remind me, what is the problem you are trying to solve?

To my mind, inclusion of "non-first-class" types in a language is a complication, not a simplification.

Btw, I saw somebody questioning whether a relation is a set of tuples or a set of attributes. It made me realise that I had been guilty of a bit of looseness when I wrote that it is a set of tuples.

A relation's body is a set of tuples.

A relation's heading is a set of attributes.

Did the questioner have some other notion of what an attribute is?

I dread the thought of changing TTM to avoid those definitions.

Also btw, a heading is a relation, an attribute is a tuple, and a tuple is a relation. True, but that way madness lies (as I believe CJD would have put it).

Sorry for butting in without reading all the correspondence.

Hugh

My proposal is simply to abandon the need for a TUPLE type in TTM and in a D language. That leaves a relation with a heading and a body which is a set of tuples, just as before. You need a new selector definition for RELATION, with scalars as arguments, and you need a change to ARRAY for getting data out of a relation.

This change has absolutely no impact on the expressiveness of the D language. It does simplify the implementation of a D based on modern GP languages. That's all.

Andl - A New Database Language - andl.org

The Forum for Discussion about The Third Manifesto and Related Matters