TTM without tuples
I claim that TTM gains no benefit whatever from including tuple types, values, variables, operators or components, and these conflict with the stated goal that 'everything is a relation'. The consequence of including it is a large section of definitions and language features which serve no useful purpose, other than in support of RM Pre 10 (1). A large part of the syntax of Tutorial D deals with tuples, to no useful purpose. I'm not aware than anyone ever uses them for, other than to write examples. Everything that is to be done can be done without them, and just as easily. They add nothing.
To achieve this would require very little change to TTM:
- Delete Rm Pre 10(1)
- Delete Rm Pre 12
- Reword RM Pro 7 as 'D shall support no tuple level operations
on relvars or relations.'. - Remove all remaining references to tuples throughout the document.
RM Pre 10 (1) defines a non-literal selector for a relation, and is unnecessary, since the RA serves that very purpose. Every possible relation value can be selected by the application of the RA to some other pre-existing relation value, which may either be a literal (RM Pre 10 (2)) or the special values DUM and DEE.
As a side note, the so-called 'structure typing' problem that makes it so hard to implement D inside some other language exists only for tuples. Without tuples, the problem fades away.
I find that tuples are an extremely useful general purpose collection type in an industrial programming language.
They are the conceptual generic type of function parameter/argument lists or underlying typical user-defined type definitions/values.
So an industrial D language should still have tuples.
That said, I assume what you are proposing is that TTM itself, or the lowest common denominator to qualify as a D language excludes tuples, so a D language CAN have them but doesn't HAVE to.
Just so. There are many languages with tuples and there is considerable variation in semantics. Some languages have named arguments, which can be passed as a tuple. Others have anonymous tuples: just a list of values of different types. C# tuples are generic across a list of specified types. TTM does not generally limit the scope of language features, so do what works for you.
The claim I make is that the specific generated tuple type in TTM adds nothing to the language (except a trivial way of creating relations) and imposes a heavy burden in extra rarely-used language features. SQL has nothing like it (except cursors I suppose). YAGNI.
Quote from dandl on April 12, 2021, 4:14 amI claim that TTM gains no benefit whatever from including tuple types, values, variables, operators or components, and these conflict with the stated goal that 'everything is a relation'. The consequence of including it is a large section of definitions and language features which serve no useful purpose, other than in support of RM Pre 10 (1). A large part of the syntax of Tutorial D deals with tuples, to no useful purpose. I'm not aware than anyone ever uses them for, other than to write examples. Everything that is to be done can be done without them, and just as easily. They add nothing.
To achieve this would require very little change to TTM:
- Delete Rm Pre 10(1)
- Delete Rm Pre 12
- Reword RM Pro 7 as 'D shall support no tuple level operations
on relvars or relations.'.- Remove all remaining references to tuples throughout the document.
RM Pre 10 (1) defines a non-literal selector for a relation, and is unnecessary, since the RA serves that very purpose. Every possible relation value can be selected by the application of the RA to some other pre-existing relation value, which may either be a literal (RM Pre 10 (2)) or the special values DUM and DEE.
As a side note, the so-called 'structure typing' problem that makes it so hard to implement D inside some other language exists only for tuples. Without tuples, the problem fades away.
You mean there's no need for a D to have first-class tuples?
That's true, though obviously relations have a body composed of zero or more tuples, and obviously any iterative use of a relation must happen somewhere else. I presume you're not going to insert the result of allowing a user to fill in a form into a relvar, or allow reports to be generated, in-language?
If your answer is that you treat relations of cardinality 1 as a special case, then have you really dispensed with tuples or have you merely wrapped them?
Also, it doesn't solve the structural typing problem. The problem exists whether you're considering relation headings or tuple headings. Conventional statically-typed semantics in popular programming languages compel using classes, records, or structs to represent relation types, and these are all nominally typed. You can easily create dynamic mechanisms to get around that, but then you lose the static typing guarantees of the host language.
That's true whether you have first-class tuples or not.
Quote from Dave Voorhis on April 12, 2021, 8:55 amQuote from dandl on April 12, 2021, 4:14 amI claim that TTM gains no benefit whatever from including tuple types, values, variables, operators or components, and these conflict with the stated goal that 'everything is a relation'. The consequence of including it is a large section of definitions and language features which serve no useful purpose, other than in support of RM Pre 10 (1). A large part of the syntax of Tutorial D deals with tuples, to no useful purpose. I'm not aware than anyone ever uses them for, other than to write examples. Everything that is to be done can be done without them, and just as easily. They add nothing.
To achieve this would require very little change to TTM:
- Delete Rm Pre 10(1)
- Delete Rm Pre 12
- Reword RM Pro 7 as 'D shall support no tuple level operations
on relvars or relations.'.- Remove all remaining references to tuples throughout the document.
RM Pre 10 (1) defines a non-literal selector for a relation, and is unnecessary, since the RA serves that very purpose. Every possible relation value can be selected by the application of the RA to some other pre-existing relation value, which may either be a literal (RM Pre 10 (2)) or the special values DUM and DEE.
As a side note, the so-called 'structure typing' problem that makes it so hard to implement D inside some other language exists only for tuples. Without tuples, the problem fades away.
You mean there's no need for a D to have first-class tuples?
That's true, though obviously relations have a body composed of zero or more tuples, and obviously any iterative use of a relation must happen somewhere else. I presume you're not going to insert the result of allowing a user to fill in a form into a relvar, or allow reports to be generated, in-language?
Iterative use of the tuples in a relation is banned -- see RM Pro 7.
You are free to provide any operators you wish to retrieve the results if a query in whatever form you like. Just like SQL -- there are transformation steps between result set and visual data.
If your answer is that you treat relations of cardinality 1 as a special case, then have you really dispensed with tuples or have you merely wrapped them?
There is no special case. Why should there be? You'll have to explain that one.
Also, it doesn't solve the structural typing problem. The problem exists whether you're considering relation headings or tuple headings. Conventional statically-typed semantics in popular programming languages compel using classes, records, or structs to represent relation types, and these are all nominally typed. You can easily create dynamic mechanisms to get around that, but then you lose the static typing guarantees of the host language.
That's true whether you have first-class tuples or not.
Not at all. The internals of a relation are opaque. You might choose to provide a conversion between 'relation' and 'set of record', but it's a conversion, not an identity. The internals are invisible to all but the implementation but in any event, the internals will not be records, they will be whatever the implementation finds most convenient.
So we are back at M. A relation is a novel type and we are unable to persuade our existing compilers to handle it as we wish. We either live with verbosity and run-time checking or allow the compiler to be extended by meta-programming. In numerous others cases we choose runtime code (see reflection, exceptions, null pointers and casts, annotations) and we can do the same here. I argue for a more general capability, and this is an excellent example of what M can do.
TTM tuples are still completely unnecessary.
Quote from dandl on April 12, 2021, 10:15 amQuote from Dave Voorhis on April 12, 2021, 8:55 amQuote from dandl on April 12, 2021, 4:14 amI claim that TTM gains no benefit whatever from including tuple types, values, variables, operators or components, and these conflict with the stated goal that 'everything is a relation'. The consequence of including it is a large section of definitions and language features which serve no useful purpose, other than in support of RM Pre 10 (1). A large part of the syntax of Tutorial D deals with tuples, to no useful purpose. I'm not aware than anyone ever uses them for, other than to write examples. Everything that is to be done can be done without them, and just as easily. They add nothing.
To achieve this would require very little change to TTM:
- Delete Rm Pre 10(1)
- Delete Rm Pre 12
- Reword RM Pro 7 as 'D shall support no tuple level operations
on relvars or relations.'.- Remove all remaining references to tuples throughout the document.
RM Pre 10 (1) defines a non-literal selector for a relation, and is unnecessary, since the RA serves that very purpose. Every possible relation value can be selected by the application of the RA to some other pre-existing relation value, which may either be a literal (RM Pre 10 (2)) or the special values DUM and DEE.
As a side note, the so-called 'structure typing' problem that makes it so hard to implement D inside some other language exists only for tuples. Without tuples, the problem fades away.
You mean there's no need for a D to have first-class tuples?
That's true, though obviously relations have a body composed of zero or more tuples, and obviously any iterative use of a relation must happen somewhere else. I presume you're not going to insert the result of allowing a user to fill in a form into a relvar, or allow reports to be generated, in-language?
Iterative use of the tuples in a relation is banned -- see RM Pro 7.
So you're presuming this new language must be a query sublanguage, and not a relationally-enabled general-purpose language like Tutorial D?
You are free to provide any operators you wish to retrieve the results if a query in whatever form you like. Just like SQL -- there are transformation steps between result set and visual data.
That's what I meant -- you still need some notion of 'tuple' to get individual records into relvars, and you presumably want to do something useful with the results of queries.
Is that allowed within your language, or is your language a sublanguage, and database updates and application of query results must necessarily happen elsewhere?
If your answer is that you treat relations of cardinality 1 as a special case, then have you really dispensed with tuples or have you merely wrapped them?
There is no special case. Why should there be? You'll have to explain that one.
It follows from the issue I noted above.
How do you get records/tuples into relvars?
How do you process the output of relational expressions/queries?
In both cases, you are semantically dealing with tuples, whether you expose them as an explicit first-class 'tuple' construct or not.
Also, it doesn't solve the structural typing problem. The problem exists whether you're considering relation headings or tuple headings. Conventional statically-typed semantics in popular programming languages compel using classes, records, or structs to represent relation types, and these are all nominally typed. You can easily create dynamic mechanisms to get around that, but then you lose the static typing guarantees of the host language.
That's true whether you have first-class tuples or not.
Not at all. The internals of a relation are opaque. You might choose to provide a conversion between 'relation' and 'set of record', but it's a conversion, not an identity. The internals are invisible to all but the implementation but in any event, the internals will not be records, they will be whatever the implementation finds most convenient.
Do relations require specification of a set of attributes?
If so, all the usual nominal vs structural problems apply.
If your relations are essentially containers of some native type T, that's fine (in and of itself) but either it's not the usual relational model and the usual operators don't apply, or it is and the usual static nominal vs structural typing issues apply.
Unless your intention is that your relational algebra implementation work on opaque "tuples" (using the term loosely here) where all type definitions are external to it?
If so, I'm not sure what that would gain.
So we are back at M. A relation is a novel type and we are unable to persuade our existing compilers to handle it as we wish. We either live with verbosity and run-time checking or allow the compiler to be extended by meta-programming. In numerous others cases we choose runtime code (see reflection, exceptions, null pointers and casts, annotations) and we can do the same here. I argue for a more general capability, and this is an excellent example of what M can do.
M doesn't exist. It has neither specification nor implementation. Thus we don't know what M can do.
TTM tuples are still completely unnecessary.
I'm not seeing it. Perhaps you can give some simple pseudocode examples to illustrate how you see that working?
What is a relation a set of? We can't just say it's a set.
What does a relation literal look like if we have no construct for denoting a tuple literal?
I find TD's TUPLE FROM r and x FROM t both useful occasionally.
Consider collection types in general. I don't know much about other languages support for. e.g., sets of integers, but surely the definition of such a type depends on the existence of a defined type for its members?
Hugh
Quote from Hugh on April 12, 2021, 1:24 pmWhat is a relation a set of? We can't just say it's a set.
Category theory has the concept of structured set. David Spivak has written several articles exploring this idea, but I'm not entirely convinced, mostly because his research is void on casting categorical perspective into relational algebra/calculus.
If a relation is a set, then which one: is it a set of tuples, or set of attributes? Then, perhaps, relation is not a structured set (such as directed graph in Spivak's approach), but something else...
So you're presuming this new language must be a query sublanguage, and not a relationally-enabled general-purpose language like Tutorial D?
Of course not. For the sake of this argument, we are talking about TD without TUPLE. Any program you can write in TD can be written without a TTM tuple type.
You are free to provide any operators you wish to retrieve the results if a query in whatever form you like. Just like SQL -- there are transformation steps between result set and visual data.
That's what I meant -- you still need some notion of 'tuple' to get individual records into relvars, and you presumably want to do something useful with the results of queries.
No you don't, you can devise whatever operators you wish, but there need be tuple type. For example, the following is a function with named arguments that returns a relation as its value:
RELATION(S#: "S99", SNAME: "Brown", STATUS: 99, CITY: "Moscow")
How do you process the output in Rel? You cannot iterate over tuples so as I understand it, you export it as an ARRAY. No change.
How do you get records/tuples into relvars?
The usual way, via the literals, selectors and the RA. No change.
Do relations require specification of a set of attributes?
As per TTM, relations specify a Heading. No change.
Please note: this proposal is simply to remove TUPLE from TTM and therefore from TD. Take any program in TD you like, find every occurrence of the word TUPLE and remove it. Replace every RELATION selector with a new syntax of your choosing, preferably in a syntax similar to that of other types. We're done.
The intent of this post is simply to show that you don't need a tuple type in TTM and you don't need TUPLE in the language. I fail to see how that can be hard to understand.
Once you accept that this is so, we can move on to more interesting issues, such as how to remove the tuple-like constructs in WHERE and EXTEND.
A consequence of removing tuple types from TTM is that it greatly simplifies the task of merging TTM into an existing GP language such as Java, but this is a separate topic. I prefer to deal with it separately.
Quote from Hugh on April 12, 2021, 1:24 pm
What is a relation a set of? We can't just say it's a set.
A relation is defined as consisting of a heading and a body, consisting of a set of tuples with that heading. No change.
What does a relation literal look like if we have no construct for denoting a tuple literal?
Any convenient syntactic form that specifies a heading and a body as a set of values arranged in rows and columns. Here is the one I use in Andl:
{{name:text,age:number}
('Smith', 17),
('Jones', 35),
('Frankenstein', 199)
}
I find TD's TUPLE FROM r and x FROM t both useful occasionally.
I don't think you would miss them, there is always another way. Having reviewed my limited knowledge of TD, it's actually ARRAY that would be a problem, because it's array of tuple. This would have to be changed into array of some scalar type. It's hard to see what the implications of that would be.
Consider collection types in general. I don't know much about other languages support for. e.g., sets of integers, but surely the definition of such a type depends on the existence of a defined type for its members?
Yes, if you have 'set of X' or 'list of X' then there is always a type X, but not every collection type need be defined that way. You don't have to consider a string as a 'collection of character' or a matrix as a 'collection of vectors' or square array as a 'collection of rows'. It's a useful compositional technique, but it doesn't preclude opaque collection types. There are plenty of languages that have string as an opaque type with no concept of character (other than as a string of length 1). In the same way TTM defines relation fully as an opaque type and need not impose any obligation for there also to be a corresponding tuple type.