Quote from
Hugh on October 31, 2018, 5:08 pm
Quote from
dandl on October 31, 2018, 4:23 am
I used the word type intending some degree of generality, but in TTM terms what I'm referring to is more like a type constraint (RM Pre 23a), or pick some other word if you prefer. What about data value constraint?
We still have the same issues. A data value constraint would be one that says "the value of attribute A must be one of those specified by the item with key K (or A) in relvar T. The values in relvar T could be changed (subject to database consistency rules) without changing any software. Nothing in the software can ever depend on which values are allowed.
We cannot generalise data value constraints of this kind because we cannot refer to relvars or their attributes by reference. As per Hugh's comment, we can do something a bit similar, but only by using literals.
A type constraint defines the (constant) set of values constituting a type, so cannot reference a variable.
Constraints that directly or indirectly reference base relvars are (database) integrity constraints.
Regarding my example, where I use a relation literal to enumerate the permitted values, I have dressed it as a virtual relvar and have used integrity constraints to make sure I use values drawn from that set in other places. If we are to think of my Cases as a type, then my solution is certainly a hack, but I don't call it a type and it works fine for the purpose in hand, whereas a user-defined type would not afaics.
Hugh
Quote from
dandl on October 31, 2018, 4:23 am
I used the word type intending some degree of generality, but in TTM terms what I'm referring to is more like a type constraint (RM Pre 23a), or pick some other word if you prefer. What about data value constraint?
We still have the same issues. A data value constraint would be one that says "the value of attribute A must be one of those specified by the item with key K (or A) in relvar T. The values in relvar T could be changed (subject to database consistency rules) without changing any software. Nothing in the software can ever depend on which values are allowed.
We cannot generalise data value constraints of this kind because we cannot refer to relvars or their attributes by reference. As per Hugh's comment, we can do something a bit similar, but only by using literals.
A type constraint defines the (constant) set of values constituting a type, so cannot reference a variable.
Constraints that directly or indirectly reference base relvars are (database) integrity constraints.
Regarding my example, where I use a relation literal to enumerate the permitted values, I have dressed it as a virtual relvar and have used integrity constraints to make sure I use values drawn from that set in other places. If we are to think of my Cases as a type, then my solution is certainly a hack, but I don't call it a type and it works fine for the purpose in hand, whereas a user-defined type would not afaics.
Hugh
Coauthor of The Third Manifesto and related books.
Quote from
dandl on November 2, 2018, 4:24 am
I'm not arguing with your interpretation or your solution to the problem. You understand the limitations well and are content to work within them.
What I'm saying is that these two potentially very useful features are blocked by limitations inherent to TTM.
Some time ago we discussed the fact that types (in TTM/D and many other languages) are second class citizens (in the Strachey sense). To this I would add: relvars and attributes are also second class: "they always have to appear in person and can never be represented by a variable or expression". You cannot implement my list or lookup features because the language cannot let you unless or until those things are made first class.
FWIW I've been writing a bit of JavaScript recently. I don't like dynamic languages and I miss compiler type safety, but I do like having (almost) everything as a first-class citizen.
I'm not arguing with your interpretation or your solution to the problem. You understand the limitations well and are content to work within them.
What I'm saying is that these two potentially very useful features are blocked by limitations inherent to TTM.
Some time ago we discussed the fact that types (in TTM/D and many other languages) are second class citizens (in the Strachey sense). To this I would add: relvars and attributes are also second class: "they always have to appear in person and can never be represented by a variable or expression". You cannot implement my list or lookup features because the language cannot let you unless or until those things are made first class.
FWIW I've been writing a bit of JavaScript recently. I don't like dynamic languages and I miss compiler type safety, but I do like having (almost) everything as a first-class citizen.
Andl - A New Database Language - andl.org
Quote from
Hugh on November 2, 2018, 3:42 pm
Quote from
dandl on November 2, 2018, 4:24 am
I'm not arguing with your interpretation or your solution to the problem. You understand the limitations well and are content to work within them.
What I'm saying is that these two potentially very useful features are blocked by limitations inherent to TTM.
Some time ago we discussed the fact that types (in TTM/D and many other languages) are second class citizens (in the Strachey sense). To this I would add: relvars and attributes are also second class: "they always have to appear in person and can never be represented by a variable or expression". You cannot implement my list or lookup features because the language cannot let you unless or until those things are made first class.
FWIW I've been writing a bit of JavaScript recently. I don't like dynamic languages and I miss compiler type safety, but I do like having (almost) everything as a first-class citizen.
I'd like to understand the claimed TTM limitations better. Which of TTM's prescriptions are the culprits? (Are we now moving away from the discussion about enumerated types?)
Hugh
Quote from
dandl on November 2, 2018, 4:24 am
I'm not arguing with your interpretation or your solution to the problem. You understand the limitations well and are content to work within them.
What I'm saying is that these two potentially very useful features are blocked by limitations inherent to TTM.
Some time ago we discussed the fact that types (in TTM/D and many other languages) are second class citizens (in the Strachey sense). To this I would add: relvars and attributes are also second class: "they always have to appear in person and can never be represented by a variable or expression". You cannot implement my list or lookup features because the language cannot let you unless or until those things are made first class.
FWIW I've been writing a bit of JavaScript recently. I don't like dynamic languages and I miss compiler type safety, but I do like having (almost) everything as a first-class citizen.
I'd like to understand the claimed TTM limitations better. Which of TTM's prescriptions are the culprits? (Are we now moving away from the discussion about enumerated types?)
Hugh
Coauthor of The Third Manifesto and related books.
Quote from
dandl on November 2, 2018, 11:09 pm
It was never really about enumerated types. It's about good solutions to a common problem, about dealing with validation against a list of values. But I think I'll start a new thread about this limitation in TTM.
It was never really about enumerated types. It's about good solutions to a common problem, about dealing with validation against a list of values. But I think I'll start a new thread about this limitation in TTM.
Andl - A New Database Language - andl.org
Quote from
dandl on November 2, 2018, 11:09 pm
It was never really about enumerated types.
Then why did you write in the original message, "The question is: do such values always justify a table for each, or is there some particular criterion on which it is better to treat them as an enumerated type?"? Grrr! :twisted:
Though this does seem at least conceptually straightforward: either define a lookup table, or use a type constraint. E.g...
TYPE MyAttribute POSSREP {v CHAR CONSTRAINT isValid(v)};
VAR myvar REAL RELATION {x MyAttribute, y INT} KEY {y};
...where isValid(v) represents an arbitrary boolean function.
Unless I'm missing something here?
Quote from
dandl on November 2, 2018, 11:09 pm
It was never really about enumerated types.
Then why did you write in the original message, "The question is: do such values always justify a table for each, or is there some particular criterion on which it is better to treat them as an enumerated type?"? Grrr! :twisted:
Though this does seem at least conceptually straightforward: either define a lookup table, or use a type constraint. E.g...
TYPE MyAttribute POSSREP {v CHAR CONSTRAINT isValid(v)};
VAR myvar REAL RELATION {x MyAttribute, y INT} KEY {y};
...where isValid(v) represents an arbitrary boolean function.
Unless I'm missing something here?
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
