TTM without tuples
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. In the same vein a relation type with associated relation operators can be added to any GP language and cause no discomfort, except at precisely two points: conversions into and out of relations. The same considerations that apply to strings, matrices, indeed every other opaque data type. And the answer is simply: conversion functions.
In TD the into function is a selector with tuple arguments, and the out of function is ARRAY. There are also TUPLE FROM and TO. They are easily replaced by scalar equivalents.
In a GP language such as Java both would be functions that convert to and from the equivalent array of a record type. This is easily implemented at runtime using reflection, which is how it's already done in serialising to and from Json and XML, which also means there is obviously no issue of structural vs nominal typing.
. Ideally the compiler would take care of this: for Json, XML, TTM relation and other types. But that needs M.
Quote from dandl on April 13, 2021, 4:11 amSo 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.
Feeling compelled to point out something is "blindingly obvious" should always be an indication that you need to explain it better.
It appears what you're actually suggesting are syntax changes and feature removal. I don't see any changes to language semantics. Relations are still composed of a heading and a body of tuples. You've simply removed first-class TUPLEs, which is fairly harmless but doesn't gain you anything.
But in the usual popular programming languages, tuples aren't the problem.
The problem is that if you want static type guarantees on relation types, you're almost certainly going to represent them with static structures -- structs, classes, whatever -- and that is going to be nominal rather than structural.
Or, you can handle them dynamically at run-time, but then you don't get static type guarantees.
In the same vein a relation type with associated relation operators can be added to any GP language and cause no discomfort, except at precisely two points: conversions into and out of relations. The same considerations that apply to strings, matrices, indeed every other opaque data type. And the answer is simply: conversion functions.
In TD the into function is a selector with tuple arguments, and the out of function is ARRAY. There are also TUPLE FROM and TO. They are easily replaced by scalar equivalents.
In a GP language such as Java both would be functions that convert to and from the equivalent array of a record type. This is easily implemented at runtime using reflection, which is how it's already done in serialising to and from Json and XML, which also means there is obviously no issue of structural vs nominal typing.
Yes, but there are no static type guarantees, either.
Quote from dandl on April 13, 2021, 4:11 amIdeally the compiler would take care of this: for Json, XML, TTM relation and other types. But that needs M.
M isn't specified or implemented, so it becomes a magic wand. Not helpful.
Quote from dandl on April 13, 2021, 4:11 amSo 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.
Quote from AntC on April 13, 2021, 8:19 amQuote from dandl on April 13, 2021, 4:11 amSo 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.
Quote from dandl on April 13, 2021, 10:44 amQuote from AntC on April 13, 2021, 8:19 amQuote from dandl on April 13, 2021, 4:11 amSo 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.
The problem of static nominal vs structural typing doesn't go away by syntactically eliding tuples. It's still present for relations.
If you address it for relations, then explicit tuples are trivial.
Tuples aren't the (only) problem. Relations -- and relational expressions -- are the (root) problem.
Quote from dandl on April 13, 2021, 10:44 amQuote from AntC on April 13, 2021, 8:19 amQuote from dandl on April 13, 2021, 4:11 amSo 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)
}
That looks like tuples to me, but by all means, we don't need to name them.
What about my variable r that the value above is assigned to, what type is it? Just Relation? When I pass r into a function that takes a Relation parameter, how do I know in the function that the relation contains names and ages? Or how do I know that a particular relation is appropriate to be passed in as a parameter? What about the relation with name and address? What about when I join those, what type do I get? All is easy if its dynamic and can crash at runtime. Or if we have structural typing. Perhaps M is intended to do type inference and generate nominal types and code for us so it works in Java, kind of like Lombok does, and you need a special plugin in your editor to keep track of what you can do with which relation variable?
Quote from dandl on April 13, 2021, 10:44 amQuote from AntC on April 13, 2021, 8:19 amQuote from dandl on April 13, 2021, 4:11 amSo 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
@Dave Feeling compelled to point out something is "blindingly obvious" should always be an indication that you need to explain it better.
You need to explain it better.
- Remove the word TUPLE and every construct that depends on it.
You seem to have merely removed the Tutorial D token TUPLE, and used a CSV-like syntax to represent what is (at the 'higher level' you keep asking for) a set of tuples. You aren't, surely!, making this song and dance merely about syntax/lexing?
{{name:text,age:number}
('Smith', 17),
('Jones', 35),
('Frankenstein', 199)
}
What does ('Smith', 17) denote? What is its type? Can that syntax appear outside of a frame {{name:text, age:number} ..., ... }? If not, why not? It seems a perfectly familiar ordered tuple in many languages. If I had instead
{{age:number,name:text}
(17, 'Smith'),
(35, 'Jones'),
(199, 'Frankenstein')
}
Does that denote the same value, with the same type? (IOW what would be the result of an equality test between the two literals.) What is it that's 'the same' about the semantic structure denoted by those two superficially different bits of syntax?
The literal for DEE might be (as per Andl):
{{}}or RELATION().And before you ask, DUM might be
{{}{}}or RELATION(()).
DEE is the relation with empty heading and one tuple. DUM is the relation with empty heading and no tuples. To the extent I might be following your notation, you seem to have those round the wrong way. In the expression RELATION(()), what is the inner () denoting? What is its type?
It just isn't that hard. I'm sure you could figure it out.
What it looks like so far is you want the semantics of tuples without the keyword TUPLE.
Incidentally, I think you would find the Haskell implementation way simpler without the tuples. Forget nasty records, you don't need them.
('Smith', 17) is a valid Haskell expression. The Haskell name for the denoted data structure is "tuple". (17, 'Smith') is another Haskell expression, also denoting a "tuple". In the case of Haskell's semantics, those two tuples are not the same type, so not comparable. There's a whole bunch of Haskell library routines for dealing with "tuples", including curry and uncurry. The name comes from the logician 'Haskell Curry'. There's no lexeme/reserved word TUPLEor tuple in Haskell syntax.
"tuples" are fundamental to how Haskell (the language) works. There's no way anybody's going to program in Haskell "without the tuples".
What I've figured out so far is you mis-understand TTM's terminology in a major way; and you mis-understand Haskell's terminology in a major way.
Quote from Dave Voorhis on April 13, 2021, 11:19 amQuote from dandl on April 13, 2021, 10:44 amQuote from AntC on April 13, 2021, 8:19 amQuote from dandl on April 13, 2021, 4:11 amSo 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.
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.
If you address it for relations, then explicit tuples are trivial.
Tuples aren't the (only) problem. Relations -- and relational expressions -- are the (root) problem.
No problem at all. Relations are manipulated with no knowledge of how they might be implemented.
BTW my implementation of relations does not use records, so no structural typing inside or outside.
- Remove the word TUPLE and every construct that depends on it.
You seem to have merely removed the Tutorial D token
TUPLE, and used a CSV-like syntax to represent what is (at the 'higher level' you keep asking for) a set of tuples. You aren't, surely!, making this song and dance merely about syntax/lexing?
Merely? The proposal is to remove any mandated tuple types, values etc from TTM and D. What you think some syntactic form 'represents' is entirely in your mind.
{{name:text,age:number}
('Smith', 17),
('Jones', 35),
('Frankenstein', 199)
}What does
('Smith', 17)denote? What is its type? Can that syntax appear outside of a frame{{name:text, age:number} ..., ... }? If not, why not? It seems a perfectly familiar ordered tuple in many languages. If I had instead
It has no type and it denotes nothing. This is a complete syntactic form denoting (in its entirety) a relational value. There are no tuples.
{{age:number,name:text}(17, 'Smith'),(35, 'Jones'),(199, 'Frankenstein')}{{age:number,name:text} (17, 'Smith'), (35, 'Jones'), (199, 'Frankenstein') }{{age:number,name:text} (17, 'Smith'), (35, 'Jones'), (199, 'Frankenstein') }Does that denote the same value, with the same type? (IOW what would be the result of an equality test between the two literals.) What is it that's 'the same' about the semantic structure denoted by those two superficially different bits of syntax?
If they denote the same relational value they are equal, otherwise not. Which you surely knew.
The literal for DEE might be (as per Andl):
{{}}or RELATION().And before you ask, DUM might be
{{}{}}or RELATION(()).
DEEis the relation with empty heading and one tuple.DUMis the relation with empty heading and no tuples. To the extent I might be following your notation, you seem to have those round the wrong way. In the expressionRELATION(()), what is the inner()denoting? What is its type?
[Oops, sorry, sloppy.] You might as well ask what type is 'E' in 1.23+E99. It has no type. Those are literals. If you don't like them, I have others.
It just isn't that hard. I'm sure you could figure it out.
What it looks like so far is you want the semantics of tuples without the keyword
TUPLE.Incidentally, I think you would find the Haskell implementation way simpler without the tuples. Forget nasty records, you don't need them.
('Smith', 17)is a valid Haskell expression. The Haskell name for the denoted data structure is "tuple".(17, 'Smith')is another Haskell expression, also denoting a "tuple". In the case of Haskell's semantics, those two tuples are not the same type, so not comparable. There's a whole bunch of Haskell library routines for dealing with "tuples", includingcurryanduncurry. The name comes from the logician 'Haskell Curry'. There's no lexeme/reserved wordTUPLEortuplein Haskell syntax."tuples" are fundamental to how Haskell (the language) works. There's no way anybody's going to program in Haskell "without the tuples".
Yes, I know that, how is it relevant? Feel free to devise a Haskell relation type in whatever form you like and you might find it useful to provide a selector with a Haskell tuple as an argument. You just won't need to implement a TTM tuple type, with all the pain that involves.