Which Empty?
(I apologise again if this topic is old ground. I did a search (of TTM and this forum), but it was very cursory)
It occurs to me that I don't know/recall the answer to the following questions.
What type is the value TABLE_DEE?
What type is the value TABLE_DUM?
I've not reread the IM model recently, but I guess that the answer in that model is going to be "alpha" (or "omega").
Without an inheritance model. If values only have one type. What is the type of DUM and DEE? Are they "their own type". Are they both in a type called "Empties" or "Twiddle" or "Dee&Dum" ?
To answer my own question. TABLE_DEE and TABLE_DUM are not scalar values. They are not atoms. Hence their type in TTM is their heading. Hence (Edit: ). RELATION{TUPLE{}} and RELATION{}{} RELATION{}
Still, they are interesting examples of types of one value (and of values that are "their own type"?)
Although, is there not infinite recursion here too? Let me try with the empty set rather than DEE or DUM
The type of {} is the set containing the empty set, hence {{}}
The type of {{}} is the set containing set set containing the empty set, hence {{{}}}
and so on.
Is that a problem? The type of the empty set being the set of infinite nested empty sets.
Hence {} and {{}} and {{{}}} all have the same type (which is maybe good - and not then an example of a type with one value)
Quote from Paul Vernon on November 15, 2021, 11:31 am(I apologise again if this topic is old ground. I did a search (of TTM and this forum), but it was very cursory)
It occurs to me that I don't know/recall the answer to the following questions.
What type is the value
TABLE_DEE?What type is the value
TABLE_DUM?
TTM already contains the answer. Just read it.
They are the only values belonging to the type RELATION H where H is the null heading ie with an empty set of attributes.
In TD syntax the name is RELATION{}. See DTATRM p115.
I've not reread the IM model recently, but I guess that the answer in that model is going to be "alpha" (or "omega").
Without an inheritance model. If values only have one type. What is the type of DUM and DEE? Are they "their own type". Are they both in a type called "Empties" or "Twiddle" or "Dee&Dum" ?
In the IM that type is its own omega. See DTATRM p368.
Thanks David. Yes I was just being lazy / impatient. (I was on p115, just not reading it carefully)
So, to be clear: The (non-scalar) type RELATION{} is the set { RELATION{}{}, RELATION{TUPLE{}} } and the name of that set is RELATION{} OK, got it.
I did think of deleting my post, but not sure that is possible (short of editing it to be empty - or would that to be the empty string? :-) )
Still, I thought my "what is the type of {} " question maybe worth exploring. I guess, in TTM, the equivalent question is, what is the type of RELATION{}? I guess it has to be the set of all types (and then you can ask what is the type of that set and so on... until you get to a set that contains itself, and you can stop the recursion at infinity.)
Quote from Paul Vernon on November 15, 2021, 11:37 am...
Although, is there not infinite recursion here too? Let me try with the empty set rather than DEE or DUM
The type of
{}is the set containing the empty set, hence{{}}
No. I'm pretty sure I or somebody/many bodies already answered this on another thread. TTM adopts a Nominative aka Nominal Type system. (Also the approach with Haskell or Idris or see the long list of languages on that wiki -- which list is far from comprehensive.) Or as @dandl puts it on another thread "Many of the questions you ask have one extremely simple answer: because they're defined that way." So bare {} is not necessarily a legitimate value in programming language X unless it's defined to be -- and if it is defined to be, it must be defined to be at some type, in a Nominative type system.
If you want {} to be a value in a TTM -style language, we can see it's not of the form RELATION{} nor TUPLE{}, so it's not a non-scalar value, hence it's a scalar value.
And my immediate question would be: at what type are the elements of this set defined to be? Just because it's empty, doesn't make it an empty-set-of-nothing.
The type of
{{}}is the set containing set set containing the empty set, hence{{{}}}and so on.
Is that a problem?
Is this a value with no declared (Nominative) type? Then no it's not a "problem": it's merely not allowed in a programming language with Nominative typing. End of non-problem.
The type of the empty set being the set of infinite nested empty sets.
Hence
{}and{{}}and{{{}}}all have the same type (which is maybe good - and not then an example of a type with one value)
No there's nothing good having set-of-set-of-set in the same type as set-of-set. This is exactly what axiomatic set theory is there to avoid -- ever since Russell's paradox.
Quote from Paul Vernon on November 15, 2021, 11:37 amTo answer my own question.
TABLE_DEEandTABLE_DUMare not scalar values. They are not atoms. Hence their type in TTM is their heading. Hence (Edit:).RELATION{TUPLE{}}andRELATION{}{}RELATION{}Still, they are interesting examples of types of one value (and of values that are "their own type"?)
Although, is there not infinite recursion here too? Let me try with the empty set rather than DEE or DUM
The type of
{}is the set containing the empty set, hence{{}}The type of
{{}}is the set containing set set containing the empty set, hence{{{}}}and so on.
Is that a problem? The type of the empty set being the set of infinite nested empty sets.
Hence
{}and{{}}and{{{}}}all have the same type (which is maybe good - and not then an example of a type with one value)
I guess you're just proving that a type is not a set.
Quote from tobega on November 16, 2021, 3:58 pm
I guess you're just proving that a type is not a set.
I'm happy for a type (as far we find the concept is useful) to be just a set. TTM says it is a named set of values. I'm just taking them at their word, but finding that if that is all that a type is, contradictions appear to arise (such as the recursion in the definition of a set of typed values that I pointed out in post #77 )
Quote from Paul Vernon on November 16, 2021, 7:12 pmQuote from tobega on November 16, 2021, 3:58 pmI guess you're just proving that a type is not a set.
I'm happy for a type (as far we find the concept is useful) to be just a set. TTM says it is a named set of values. I'm just taking them at their word, but finding that if that is all that a type is, contradictions appear to arise (such as the recursion in the definition of a set of typed values that I pointed out in post #77 )
Except that it's not a contradiction. It's only a limitation of using BNF to express mutually-recursive rules.
Mathematically, logically, and in practical implementations in programming languages, it's not a problem.
Quote from tobega on November 16, 2021, 3:58 pmQuote from Paul Vernon on November 15, 2021, 11:37 amTo answer my own question.
TABLE_DEEandTABLE_DUMare not scalar values. They are not atoms. Hence their type in TTM is their heading. Hence (Edit:).RELATION{TUPLE{}}andRELATION{}{}RELATION{}Definition problems again. DEE and DUM are values of type RELATION H where H is the empty heading. Only when expressed in Tutorial D are they of type RELATION {}; in one of the other TTM languages they will take a different form.
Still, they are interesting examples of types of one value (and of values that are "their own type"?)
No, they are the (only) two values of that type.
Although, is there not infinite recursion here too? Let me try with the empty set rather than DEE or DUM
The type of
{}is the set containing the empty set, hence{{}}The type of
{{}}is the set containing set set containing the empty set, hence{{{}}}
No, these are not valid values or types in the context of TTM or TD. And no, a type is not a value so there is no regress. If there were a language with SET as a type then you would need a notation to keep 'set as a value' distinct from 'set of values comprising a type'.
and so on.
Is that a problem? The type of the empty set being the set of infinite nested empty sets.
Hence
{}and{{}}and{{{}}}all have the same type (which is maybe good - and not then an example of a type with one value)I guess you're just proving that a type is not a set.
A type is a named set of values, in TTM and in most other languages. You won't easily find a contradiction in that definition. It seems to have stood the test of time.
BTW the language that comes to mind in this context is Smalltalk. If memory serves every value is an object, an object belongs to a class, a class is a value, there is a 'class of class' and an ingenious (or desperate) bit of trickery to avoid the regress.
Quote from dandl on November 16, 2021, 11:51 pmQuote from tobega on November 16, 2021, 3:58 pmQuote from Paul Vernon on November 15, 2021, 11:37 amTo answer my own question.
TABLE_DEEandTABLE_DUMare not scalar values. They are not atoms. Hence their type in TTM is their heading. Hence (Edit:).RELATION{TUPLE{}}andRELATION{}{}RELATION{}Definition problems again. DEE and DUM are values of type RELATION H where H is the empty heading. Only when expressed in Tutorial D are they of type RELATION {}; in one of the other TTM languages they will take a different form.
Still, they are interesting examples of types of one value (and of values that are "their own type"?)
No, they are the (only) two values of that type.
Although, is there not infinite recursion here too? Let me try with the empty set rather than DEE or DUM
The type of
{}is the set containing the empty set, hence{{}}The type of
{{}}is the set containing set set containing the empty set, hence{{{}}}No, these are not valid values or types in the context of TTM or TD. And no, a type is not a value so there is no regress. If there were a language with SET as a type then you would need a notation to keep 'set as a value' distinct from 'set of values comprising a type'.
and so on.
Is that a problem? The type of the empty set being the set of infinite nested empty sets.
Hence
{}and{{}}and{{{}}}all have the same type (which is maybe good - and not then an example of a type with one value)I guess you're just proving that a type is not a set.
A type is a named set of values, in TTM and in most other languages. You won't easily find a contradiction in that definition. It seems to have stood the test of time.
No, you are conflating essence with representation. It's fine to represent a type as a set of all possible values, but that's not what it "is", any more than an integer "is" a certain number of bits. The type of type is type, but you can produce a set of all types, where type is a member.
BTW the language that comes to mind in this context is Smalltalk. If memory serves every value is an object, an object belongs to a class, a class is a value, there is a 'class of class' and an ingenious (or desperate) bit of trickery to avoid the regress.
A class in smalltalk is an object.