Are inclusion dependencies reducible to foreign-key dependencies?
Quote from Erwin on October 18, 2019, 7:15 amQuote from AntC on October 17, 2019, 1:52 amWell if I have an empty relation of degree 1, what is the MST of its attribute? I want to say that for each
rootTthere is anomegaTwhich is 'the' subtype ofTthat contains no values, in whichTis the declared (or inferred) attribute type.In that case, I'd suspect we have no need for omega. That is, types form a hierarchy (or semilattice with alpha at the top) not a lattice. In that case, I question whether we need alpha, especially since there can be no scalar types at alpha.
"What is the MST of its attribute" is a wrong question to ask. MST is a property of a value, not of an attribute of a nonscalar value (an attribute is a member of a heading / nonscalar type declaration, but an attribute is not a value). So while you can ask what the MST is of an empty relation of some relation type, and it would be answerable, your question isn't really answerable.
Correct.
The MST of your empty relation will have an attribute declared to be of type the minimal type corresponding to the attribute type declaration in the relation type your empty relation is declared to be of (OMEGA if that attribute is scalar).
Not correct. The attribute is declared as per some heading somewhere. Every attribute is required to give the name of its type. and that will be its declared type.If the null relation is the result of a JOIN or similar, it's still possible to trace the declared type back to where it was declared. The IM has no problem with that.
But the minimal type is quite a different beast, and is never the MST of any value. Down that path lies type madness. Letting the MST default to be the declared type is safe and always works, AFAICT.
Having OMEGA on the scalars is a prerequisite, or at least very hard to avoid, for doing nonscalar inheritance the way TTM (/its authors) wants to do it.
Your alternative creates "difficulties" once you start creating union types. You must see to it that you also create "the" corresponding empty type of that union type, and how it relates to "the" empty types corresponding to the participants in the union. You're going to have lots and lots of empty types at the bottom of your type lattice.
The TTM IM was built on the (alas unenforceable) assumption that the type system IS a lattice (well three lattices if my understanding of lattices is correct -scalars, tuples, relations-), which guarantees a unique MST for every value in the system (which, e.g., facilitates handling literals as an expression of declared type that MST).
Yes. I'm not going to argue, but neither do I really understand what you're saying about union types. So best to let it pass.
Quote from dandl on October 18, 2019, 7:50 amQuote from Erwin on October 18, 2019, 7:15 am
The MST of your empty relation will have an attribute declared to be of type the minimal type corresponding to the attribute type declaration in the relation type your empty relation is declared to be of (OMEGA if that attribute is scalar).
Not correct. The attribute is declared as per some heading somewhere. Every attribute is required to give the name of its type. and that will be its declared type.If the null relation is the result of a JOIN or similar, it's still possible to trace the declared type back to where it was declared. The IM has no problem with that.
But the minimal type is quite a different beast, and is never the MST of any value. Down that path lies type madness. Letting the MST default to be the declared type is safe and always works, AFAICT.
Not sure what you're declaring incorrect. I ***DID*** say "attribute ***declared*** to be of type ...". It's possible to philosophize to no end over whether an attribute "is" or "merely provides" a declaration of something, but I'm not eager to engage.
And to say the minimal type is never the MST of any value, is ***manifestly incorrect*** at least with the IM as it stands. A minimal relation type is ***never*** itself empty (like OMEGA and all the minimal tuple types are indeed), since they ***always*** contain an empty relation as a legitimate value of that type and as I explored in this thread a few posts ago, it looks like some minimal relation types aren't even limited to cardinality 1.
It accounts for some surprising effects that might not have been anticipated even by the authors, but whether those surprising effects really qualify as "madness" is still another discussion, or well, will at least require more than just a bit of handwaving to get agreed upon, seriously.
And "letting the MST default to the declared type" is weasling words together so they become entirely meaningless. A value carries around a flag indicating its type and that flag cannot be but indicating the MST. MST goes with values, declared type goes with variables and expressions. Each value carries around its type flag and that flag is always there and there just is no question of letting it "default" to anything. If there were, then that would open the door to any given value, say, the number 3, starting to behave ***differently*** on account of having originated (/selected) in an expression that was of declared type PRIME as opposed to INT. Do you really want that ? I don't.
Quote from Erwin on October 18, 2019, 8:51 amQuote from dandl on October 18, 2019, 7:50 amQuote from Erwin on October 18, 2019, 7:15 amThe MST of your empty relation will have an attribute declared to be of type the minimal type corresponding to the attribute type declaration in the relation type your empty relation is declared to be of (OMEGA if that attribute is scalar).
Not correct. The attribute is declared as per some heading somewhere. Every attribute is required to give the name of its type. and that will be its declared type.If the null relation is the result of a JOIN or similar, it's still possible to trace the declared type back to where it was declared. The IM has no problem with that.
But the minimal type is quite a different beast, and is never the MST of any value. Down that path lies type madness. Letting the MST default to be the declared type is safe and always works, AFAICT.
Not sure what you're declaring incorrect. I ***DID*** say "attribute ***declared*** to be of type ...". It's possible to philosophize to no end over whether an attribute "is" or "merely provides" a declaration of something, but I'm not eager to engage.
And to say the minimal type is never the MST of any value, is ***manifestly incorrect*** at least with the IM as it stands. A minimal relation type is ***never*** itself empty (like OMEGA and all the minimal tuple types are indeed), since they ***always*** contain an empty relation as a legitimate value of that type and as I explored in this thread a few posts ago, it looks like some minimal relation types aren't even limited to cardinality 1.
It accounts for some surprising effects that might not have been anticipated even by the authors, but whether those surprising effects really qualify as "madness" is still another discussion, or well, will at least require more than just a bit of handwaving to get agreed upon, seriously.
And "letting the MST default to the declared type" is weasling words together so they become entirely meaningless. A value carries around a flag indicating its type and that flag cannot be but indicating the MST. MST goes with values, declared type goes with variables and expressions. Each value carries around its type flag and that flag is always there and there just is no question of letting it "default" to anything. If there were, then that would open the door to any given value, say, the number 3, starting to behave ***differently*** on account of having originated (/selected) in an expression that was of declared type PRIME as opposed to INT. Do you really want that ? I don't.
If I might interject here, for two reasons...
One, I agree with Erwin's take, but I suggest looking at Date's Type Inheritance and Relational Theory to see if the topic is covered there. I vaguely recall that it is, but I still haven't had a chance to confirm it one way or another.
Two, to raise a very minor quibble with Erwin's use of terminology, and only because it was the basis (on another forum) for a somewhat silly debate that lasted -- if I recall correctly -- about three years. The quibble: A flag is a (boolean) indicator, typically denoting presence or absence of some factor. A tag is a metadata attribute. Therefore, it's a type tag that indicates the type of a value, not a type flag.
Interjection over.
Quote from Dave Voorhis on October 18, 2019, 9:06 amQuote from Erwin on October 18, 2019, 8:51 amQuote from dandl on October 18, 2019, 7:50 amQuote from Erwin on October 18, 2019, 7:15 amThe MST of your empty relation will have an attribute declared to be of type the minimal type corresponding to the attribute type declaration in the relation type your empty relation is declared to be of (OMEGA if that attribute is scalar).
Not correct. The attribute is declared as per some heading somewhere. Every attribute is required to give the name of its type. and that will be its declared type.If the null relation is the result of a JOIN or similar, it's still possible to trace the declared type back to where it was declared. The IM has no problem with that.
But the minimal type is quite a different beast, and is never the MST of any value. Down that path lies type madness. Letting the MST default to be the declared type is safe and always works, AFAICT.
Not sure what you're declaring incorrect. I ***DID*** say "attribute ***declared*** to be of type ...". It's possible to philosophize to no end over whether an attribute "is" or "merely provides" a declaration of something, but I'm not eager to engage.
And to say the minimal type is never the MST of any value, is ***manifestly incorrect*** at least with the IM as it stands. A minimal relation type is ***never*** itself empty (like OMEGA and all the minimal tuple types are indeed), since they ***always*** contain an empty relation as a legitimate value of that type and as I explored in this thread a few posts ago, it looks like some minimal relation types aren't even limited to cardinality 1.
It accounts for some surprising effects that might not have been anticipated even by the authors, but whether those surprising effects really qualify as "madness" is still another discussion, or well, will at least require more than just a bit of handwaving to get agreed upon, seriously.
And "letting the MST default to the declared type" is weasling words together so they become entirely meaningless. A value carries around a flag indicating its type and that flag cannot be but indicating the MST. MST goes with values, declared type goes with variables and expressions. Each value carries around its type flag and that flag is always there and there just is no question of letting it "default" to anything. If there were, then that would open the door to any given value, say, the number 3, starting to behave ***differently*** on account of having originated (/selected) in an expression that was of declared type PRIME as opposed to INT. Do you really want that ? I don't.
If I might interject here, for two reasons...
One, I agree with Erwin's take, but I suggest looking at Date's Type Inheritance and Relational Theory to see if the topic is covered there. I vaguely recall that it is, but I still haven't had a chance to confirm it one way or another.
Two, to raise a very minor quibble with Erwin's use of terminology, and only because it was the basis (on another forum) for a somewhat silly debate that lasted -- if I recall correctly -- about three years. The quibble: A flag is a (boolean) indicator, typically denoting presence or absence of some factor. A tag is a metadata attribute. Therefore, it's a type tag that indicates the type of a value, not a type flag.
Interjection over.
I'm pretty certain that "flag that says 'I am an integer'" was not my invention. Never thought of your kind of "flag" when I saw it used as I did. Just saw the value carrying around a flag like armies do (/did).
Chpt. 18 explicitly mentions the fact that minimal relation types are nonempty, and ex. 19.3 uses that observation as an answer to the question, but nowhere does there appear to be any discussion of (alleged) disadvantages of this being the case. Only did a quick skim though.
Quote from AntC on October 18, 2019, 7:18 am"Given an arbitrary pair of distinct scalar types named T1 and T2, respectively, with corresponding sets of scalar
values S1 and S2, respectively, the names T1 and T2 shall be distinct and the sets S1 and S2 shall be
disjoint; in other words, two scalar types shall be equal—i.e., the same type—if and only if they have the
same name (and therefore the same set of values)."The "and therefore" at the end is just wrong in case either of S1, S2 are empty: their intersection is empty, therefore they're disjoint. If both are empty, they're disjoint and equal sets.
There are no empty types in TTM ex IM. Every type has an example value.
It's not until you get into the IM and consider union and dummy types that (a) values belong to more than one type (b) some types are empty.
And/or the author of RM Pre 1 doesn't understand nominative typing: if two types have distinct names, they're not the same type, irrespective of whether those names denote the same set of values. Specifically we've got empty sets of values at omegaT1, omegaT2 or leafT1, leafT2 whatever we're calling them.
That bothered me from the outset. I assumed it meant that the 17 as a member of prime_numbers is not the 17 as a member of odd_numbers. They are not the 'very same value', and you would need a conversion function before you could compare them. Yes, that does seem a bit weird.
RM Pre 1 goes on to a rather wooly exclusion "... with the exception of the system-defined type omega ...", but that's talking about the definition of a type, not its set of values.
Lots of TTM ex IM reads badly with the IM lurking in the shadows. This one doesn't bother me (much).
Quote from Erwin on October 18, 2019, 8:51 amQuote from dandl on October 18, 2019, 7:50 amQuote from Erwin on October 18, 2019, 7:15 am
The MST of your empty relation will have an attribute declared to be of type the minimal type corresponding to the attribute type declaration in the relation type your empty relation is declared to be of (OMEGA if that attribute is scalar).
Not correct. The attribute is declared as per some heading somewhere. Every attribute is required to give the name of its type. and that will be its declared type.If the null relation is the result of a JOIN or similar, it's still possible to trace the declared type back to where it was declared. The IM has no problem with that.
But the minimal type is quite a different beast, and is never the MST of any value. Down that path lies type madness. Letting the MST default to be the declared type is safe and always works, AFAICT.
Not sure what you're declaring incorrect. I ***DID*** say "attribute ***declared*** to be of type ...". It's possible to philosophize to no end over whether an attribute "is" or "merely provides" a declaration of something, but I'm not eager to engage.
You said the attribute of 'my' relation will have an attribute declared as minimal, and it did not. I wrote only about attributes declared with types ranging from root to leaf but not beyond. I see no purpose in a compiler that allows types to be declared as maximal or minimal, with compiler keywords corresponding to alpha and omega. The whole point that I understand Brian and you to be making was that the null value of a relation with attributes declared with ordinary types would magically transform into maximal (Brian) or minimal (you) versions, with various unsavoury consequences.
And to say the minimal type is never the MST of any value, is ***manifestly incorrect*** at least with the IM as it stands. A minimal relation type is ***never*** itself empty (like OMEGA and all the minimal tuple types are indeed), since they ***always*** contain an empty relation as a legitimate value of that type and as I explored in this thread a few posts ago, it looks like some minimal relation types aren't even limited to cardinality 1.
It seems that D&D agree with you. I now find that TIRT ch19 does indeed contemplate explicit use of these keywords and spells out the existence of various relational values based on them. And p355 has a nice little diagram confirming what you say. Bummer!
It accounts for some surprising effects that might not have been anticipated even by the authors, but whether those surprising effects really qualify as "madness" is still another discussion, or well, will at least require more than just a bit of handwaving to get agreed upon, seriously.
Leaving out the specific cases of DUM and DEE and the complications of RVAs and TVAs for now, TIRT19 says the MST of any null relation is omega wall to wall, so the MST of every null value with a given set of attribute names is the same. Point conceded, although still with reservations as to whether D&D really understood what they were getting into.
So what does that say for comparing null values? For that we have to go back to ch09. My reading of p176 is that null values of different declared types (regardless of MST) will always fail the compile-time check. YMMV.
And "letting the MST default to the declared type" is weasling words together so they become entirely meaningless.
My words may not be sufficiently formal, but I think they do reflect the intent of TIRT ch09 p176.
A value carries around a flag indicating its type and that flag cannot be but indicating the MST. MST goes with values, declared type goes with variables and expressions. Each value carries around its type flag and that flag is always there and there just is no question of letting it "default" to anything. If there were, then that would open the door to any given value, say, the number 3, starting to behave ***differently*** on account of having originated (/selected) in an expression that was of declared type PRIME as opposed to INT. Do you really want that ? I don't.
No, I don't buy any of that, and there is plenty on the subject in TIRT. Every value is associated with a type name (not a flag). The obvious source of that type name is the variable, declaration, selector or operator that produced the value. I see no compelling reason for the MST of every value to be continuously recalculated at every point except where it is actually needed. The name of any type of which it is a value will do for most purposes.
So 3 is an INTEGER, and only gets reclassified as a PRIME_INTEGER or an ODD_INTEGER or a SINGLE_DIGIT_INTEGER in case it matters.
My position is that it is redundant, and possibly problematic to include the heading with the value. Consider:
VAR X REL {A ODD, B ODD};
X := REL {A INT, B INT}{TUP {A 5, B 7}}
Since both 5 and 7 are members of ODD, the MST of the RHS of the assignment is REL {A ODD, B ODD}. The RHS can be evaluated at compile time, along with the MST of the result.
(1) Should a compiler error be thrown because REL{A INT, B INT} is not a subtype of REL {A ODD, B ODD}?
(2) Should a compiler error be thrown when the most-specific type of a relation constant does not match its declared type?
Finally, REL {A ALPHA, B ALPHA}{} and REL {A OMEGA, B OMEGA}{} denote the same value. Quibbling about my usage of either is therefore moot.
Brian
Quote from Brian S on October 19, 2019, 2:17 pmMy position is that it is redundant, and possibly problematic to include the heading with the value. Consider:
VAR X REL {A ODD, B ODD};
X := REL {A INT, B INT}{TUP {A 5, B 7}}
Since both 5 and 7 are members of ODD, the MST of the RHS of the assignment is REL {A ODD, B ODD}. The RHS can be evaluated at compile time, along with the MST of the result.
(1) Should a compiler error be thrown because REL{A INT, B INT} is not a subtype of REL {A ODD, B ODD}?
(2) Should a compiler error be thrown when the most-specific type of a relation constant does not match its declared type?
Finally, REL {A ALPHA, B ALPHA}{} and REL {A OMEGA, B OMEGA}{} denote the same value. Quibbling about my usage of either is therefore moot.
Brian
To my mind, no and no.
The fact that the programmer chose to explicitize '{A INT, B INT}' in 'REL {A INT, B INT}{TUP {A 5, B 7}}' does not make a difference. It's just an optical illusion, so to speak, possibly deluding some compiler writers / language definers into believing that this "must" influence [the way the compiler determines] the declared type the expression on the RHS has.
Now you consider REL {TUP{A 5, B 7}}, which is the way the vast majority of programmers would certainly prefer to write it.
What other option is there but to treat this as an expression of declared type the same as the MST of the value ? What reasons are there for suddenly doing anything different if the programmer chooses to add those noise words '{A INT, B INT}' to what he minimally needed to write ?
Quote from dandl on October 19, 2019, 1:04 amQuote from Erwin on October 18, 2019, 8:51 amQuote from dandl on October 18, 2019, 7:50 amQuote from Erwin on October 18, 2019, 7:15 am
The MST of your empty relation will have an attribute declared to be of type the minimal type corresponding to the attribute type declaration in the relation type your empty relation is declared to be of (OMEGA if that attribute is scalar).
Not correct. The attribute is declared as per some heading somewhere. Every attribute is required to give the name of its type. and that will be its declared type.If the null relation is the result of a JOIN or similar, it's still possible to trace the declared type back to where it was declared. The IM has no problem with that.
But the minimal type is quite a different beast, and is never the MST of any value. Down that path lies type madness. Letting the MST default to be the declared type is safe and always works, AFAICT.
Not sure what you're declaring incorrect. I ***DID*** say "attribute ***declared*** to be of type ...". It's possible to philosophize to no end over whether an attribute "is" or "merely provides" a declaration of something, but I'm not eager to engage.
You said the attribute of 'my' relation will have an attribute declared as minimal, and it did not. I wrote only about attributes declared with types ranging from root to leaf but not beyond. I see no purpose in a compiler that allows types to be declared as maximal or minimal, with compiler keywords corresponding to alpha and omega. The whole point that I understand Brian and you to be making was that the null value of a relation with attributes declared with ordinary types would magically transform into maximal (Brian) or minimal (you) versions, with various unsavoury consequences.
And to say the minimal type is never the MST of any value, is ***manifestly incorrect*** at least with the IM as it stands. A minimal relation type is ***never*** itself empty (like OMEGA and all the minimal tuple types are indeed), since they ***always*** contain an empty relation as a legitimate value of that type and as I explored in this thread a few posts ago, it looks like some minimal relation types aren't even limited to cardinality 1.
It seems that D&D agree with you. I now find that TIRT ch19 does indeed contemplate explicit use of these keywords and spells out the existence of various relational values based on them. And p355 has a nice little diagram confirming what you say. Bummer!
It accounts for some surprising effects that might not have been anticipated even by the authors, but whether those surprising effects really qualify as "madness" is still another discussion, or well, will at least require more than just a bit of handwaving to get agreed upon, seriously.
Leaving out the specific cases of DUM and DEE and the complications of RVAs and TVAs for now, TIRT19 says the MST of any null relation is omega wall to wall, so the MST of every null value with a given set of attribute names is the same. Point conceded, although still with reservations as to whether D&D really understood what they were getting into.
So what does that say for comparing null values? For that we have to go back to ch09. My reading of p176 is that null values of different declared types (regardless of MST) will always fail the compile-time check. YMMV.
And "letting the MST default to the declared type" is weasling words together so they become entirely meaningless.
My words may not be sufficiently formal, but I think they do reflect the intent of TIRT ch09 p176.
A value carries around a flag indicating its type and that flag cannot be but indicating the MST. MST goes with values, declared type goes with variables and expressions. Each value carries around its type flag and that flag is always there and there just is no question of letting it "default" to anything. If there were, then that would open the door to any given value, say, the number 3, starting to behave ***differently*** on account of having originated (/selected) in an expression that was of declared type PRIME as opposed to INT. Do you really want that ? I don't.
No, I don't buy any of that, and there is plenty on the subject in TIRT. Every value is associated with a type name (not a flag). The obvious source of that type name is the variable, declaration, selector or operator that produced the value. I see no compelling reason for the MST of every value to be continuously recalculated at every point except where it is actually needed. The name of any type of which it is a value will do for most purposes.
So 3 is an INTEGER, and only gets reclassified as a PRIME_INTEGER or an ODD_INTEGER or a SINGLE_DIGIT_INTEGER in case it matters.
Quote from dandl on October 19, 2019, 1:04 amQuote from Erwin on October 18, 2019, 8:51 amQuote from dandl on October 18, 2019, 7:50 amQuote from Erwin on October 18, 2019, 7:15 am
The MST of your empty relation will have an attribute declared to be of type the minimal type corresponding to the attribute type declaration in the relation type your empty relation is declared to be of (OMEGA if that attribute is scalar).
Not correct. The attribute is declared as per some heading somewhere. Every attribute is required to give the name of its type. and that will be its declared type.If the null relation is the result of a JOIN or similar, it's still possible to trace the declared type back to where it was declared. The IM has no problem with that.
But the minimal type is quite a different beast, and is never the MST of any value. Down that path lies type madness. Letting the MST default to be the declared type is safe and always works, AFAICT.
Not sure what you're declaring incorrect. I ***DID*** say "attribute ***declared*** to be of type ...". It's possible to philosophize to no end over whether an attribute "is" or "merely provides" a declaration of something, but I'm not eager to engage.
You said the attribute of 'my' relation will have an attribute declared as minimal, and it did not. I wrote only about attributes declared with types ranging from root to leaf but not beyond. I see no purpose in a compiler that allows types to be declared as maximal or minimal, with compiler keywords corresponding to alpha and omega. The whole point that I understand Brian and you to be making was that the null value of a relation with attributes declared with ordinary types would magically transform into maximal (Brian) or minimal (you) versions, with various unsavoury consequences.
And to say the minimal type is never the MST of any value, is ***manifestly incorrect*** at least with the IM as it stands. A minimal relation type is ***never*** itself empty (like OMEGA and all the minimal tuple types are indeed), since they ***always*** contain an empty relation as a legitimate value of that type and as I explored in this thread a few posts ago, it looks like some minimal relation types aren't even limited to cardinality 1.
It seems that D&D agree with you. I now find that TIRT ch19 does indeed contemplate explicit use of these keywords and spells out the existence of various relational values based on them. And p355 has a nice little diagram confirming what you say. Bummer!
It accounts for some surprising effects that might not have been anticipated even by the authors, but whether those surprising effects really qualify as "madness" is still another discussion, or well, will at least require more than just a bit of handwaving to get agreed upon, seriously.
Leaving out the specific cases of DUM and DEE and the complications of RVAs and TVAs for now, TIRT19 says the MST of any null relation is omega wall to wall, so the MST of every null value with a given set of attribute names is the same. Point conceded, although still with reservations as to whether D&D really understood what they were getting into.
So what does that say for comparing null values? For that we have to go back to ch09. My reading of p176 is that null values of different declared types (regardless of MST) will always fail the compile-time check. YMMV.
And "letting the MST default to the declared type" is weasling words together so they become entirely meaningless.
My words may not be sufficiently formal, but I think they do reflect the intent of TIRT ch09 p176.
A value carries around a flag indicating its type and that flag cannot be but indicating the MST. MST goes with values, declared type goes with variables and expressions. Each value carries around its type flag and that flag is always there and there just is no question of letting it "default" to anything. If there were, then that would open the door to any given value, say, the number 3, starting to behave ***differently*** on account of having originated (/selected) in an expression that was of declared type PRIME as opposed to INT. Do you really want that ? I don't.
No, I don't buy any of that, and there is plenty on the subject in TIRT. Every value is associated with a type name (not a flag). The obvious source of that type name is the variable, declaration, selector or operator that produced the value. I see no compelling reason for the MST of every value to be continuously recalculated at every point except where it is actually needed. The name of any type of which it is a value will do for most purposes.
So 3 is an INTEGER, and only gets reclassified as a PRIME_INTEGER or an ODD_INTEGER or a SINGLE_DIGIT_INTEGER in case it matters.
I explained a few posts before that "flag" was meant as "carrying around a flag saying "I am a Scot" or "I am a Belgian" ". That kind of flag. The type name is written in letters as well as in colours on the flag.
Quote from Brian S on October 19, 2019, 2:17 pmMy position is that it is redundant, and possibly problematic to include the heading with the value. Consider:
I think you need to read TIRT.
VAR X REL {A ODD, B ODD};
X := REL {A INT, B INT}{TUP {A 5, B 7}}
Since both 5 and 7 are members of ODD, the MST of the RHS of the assignment is REL {A ODD, B ODD}. The RHS can be evaluated at compile time, along with the MST of the result.
An assignment does not have an MST. It's enough to say that the assignment is permitted and that this is guaranteed by compile time checking of the literal value, and the variable takes on that value (a single tuple, A=5, B=7). The value INT A=5 was always and at the same time the value ODD A=5 so nothing has changed. The values are the same, but by embedding them in a relation with this particular heading the results of certain future uses of the value will be affected (by the relation type signature).
(1) Should a compiler error be thrown because REL{A INT, B INT} is not a subtype of REL {A ODD, B ODD}?
No. See TIRT. If they were not literal values then a runtime check would be needed, and those can fail.
(2) Should a compiler error be thrown when the most-specific type of a relation constant does not match its declared type?
Finally, REL {A ALPHA, B ALPHA}{} and REL {A OMEGA, B OMEGA}{} denote the same value. Quibbling about my usage of either is therefore moot..
No, they do not. The values are not equal because they do not satisfy the necessary type relationships. Neither are they the same value as REL { A INT, B INT }{} or REL { A ODD, B ODD }{}. They are all different values of different types that happen to share the same MST. See TIRT p176.