The Third Manifesto ForumThe Third Manifesto: TTM General discussionDictionaries

Please or Register to create posts and topics.

Dictionaries

#1 · May 6, 2021, 11:06 am

Quote from Hugh on May 6, 2021, 11:06 am
I refer to Dave Voorhis’s “dictionary” proposal that has been advanced and discussed under the rubric Tuples FTW.

In brief, he proposes a shorthand for defining a set of user-defined types that each have just a single possrep and a single possrep component. In each case the possrep name is the same as the type name and the possrep component name is Value. The purpose is much the same as that of standard SQL’s so-called distinct types: to provide a way of avoiding traps arising from inappropriate comparisons, especially ones that are implicit in operations such as joins on relations.

Here, according to my understanding, is an example, showing how it might be implemented in Rel:

Ex. 1

Dictionary;
SNO CHAR;
PNO CHAR;

End Dictionary;

As far as the type definitions are concerned this is equivalent to

Ex. 2

TYPE SNO POSSREP { Value CHAR };
TYPE PNO POSSREP { Value CHAR };

but there are two more points to the proposal. Calling those types dictionary types and their defining statements dictionary elements:

The definition of a variable with declared type a dictionary type and name the name of that type need not repeat the name. So VAR SNO; is short for VAR SNO SNO;

The same applies to declarations of objects such as attributes, parameters, and possrep components:

Ex. 3

VAR SP BASE REL{SNO, PNO, QTY INT} KEY{SNO, PNO};

≡

VAR SP BASE REL{SNO SNO, PNO PNO, QTY INT}
KEY{SNO, PNO};

Ex. 4

OPERATOR CheckSNO {SNO} RETURNS BOOLEAN;

RETURN Left(THE_Value(SNO),1) = 'S';

END OPERATOR;

≡

OPERATOR CheckSNO {SNO SNO} RETURNS BOOLEAN;

RETURN Left(THE_Value(SNO),1) = 'S';

END OPERATOR;

Ex. 5

Assume TypeX is a dictionary type. Then

TYPE TwinX POSSREP { TypeX, TypeX2 TypeX};

≡

TYPE TwinX POSSREP { TypeX TypeX, TypeX2 TypeX};

Provision is made for the same default type to be used for more than one object name by allowing several names to be specified in the same dictionary element.

Ex. 6

Dictionary;
SNO, SNO1, SNO2 CHAR;
PNO, PNO1, PNO2 CHAR;

End Dictionary;

The defined types are just SNO and PNO as in Ex 1, but the declared type names for objects named SNO1 or SNO2 can be omitted in the same manner as for objects named SNO. A similar observation applies to objects name PNO1 or PNO2.

Questions:

I know that some of these may have been answered already (after I had first drafted this posting) but I decided to leave them in for completeness.

Assume the dictionary is as defined in Ex. 6.

Q1:      Regarding Ex. 4, can the RETURNS clause be omitted such that the operator’s declared type name defaults to the operator’s name?

Q2:      Are the equivalencen given Ex 3-5 correct? E.g, this a legal relvar definition?

VAR S BASE REL{SNO SNO, NAME CHAR, CITY CHAR} KEY{SNO};

Q3:      Is this a legal relvar definition?

VAR X BASE REL{SNO INT} KEY{SNO};

Q4:      Given relvar R of heading {A INT}, is this expression legal:

R RENAME {A AS SNO}

Q5:      Given relvar R of heading {A INT}, is this expression legal:

EXTEND R : {SNO := A + 1}

Q6:      The database is to be extended with some new relvars and it is desired to use new dictionary types for some of the attributes. How can these additional dictionary types be added? (I assume use of INSERT on the relevant catalog relvar would be one not-very-convenient method. Right?)

Q7:      Possibly a stupid question. Couldn’t system-defined scalar types be assumed to be dictionary types too? For example, couldn’t this be legal?

VAR CHAR;

If not, why not? In fact, why can’t all scalar types be dictionary types? I realise that would need a different way of specifying additional names as in Ex. 6. I also realise that expressions such as Value(Value(CHAR)), and so on ad infinitum would then be legal!

I refer to Dave Voorhis’s “dictionary” proposal that has been advanced and discussed under the rubric Tuples FTW.

In brief, he proposes a shorthand for defining a set of user-defined types that each have just a single possrep and a single possrep component. In each case the possrep name is the same as the type name and the possrep component name is Value. The purpose is much the same as that of standard SQL’s so-called distinct types: to provide a way of avoiding traps arising from inappropriate comparisons, especially ones that are implicit in operations such as joins on relations.

Here, according to my understanding, is an example, showing how it might be implemented in Rel:

Ex. 1

Dictionary;
SNO CHAR;
PNO CHAR;

End Dictionary;

As far as the type definitions are concerned this is equivalent to

Ex. 2

TYPE SNO POSSREP { Value CHAR };
TYPE PNO POSSREP { Value CHAR };

but there are two more points to the proposal. Calling those types dictionary types and their defining statements dictionary elements:

The definition of a variable with declared type a dictionary type and name the name of that type need not repeat the name. So VAR SNO; is short for VAR SNO SNO;

The same applies to declarations of objects such as attributes, parameters, and possrep components:

Ex. 3

VAR SP BASE REL{SNO, PNO, QTY INT} KEY{SNO, PNO};

≡

VAR SP BASE REL{SNO SNO, PNO PNO, QTY INT}
KEY{SNO, PNO};

Ex. 4

OPERATOR CheckSNO {SNO} RETURNS BOOLEAN;

RETURN Left(THE_Value(SNO),1) = 'S';

END OPERATOR;

≡

OPERATOR CheckSNO {SNO SNO} RETURNS BOOLEAN;

RETURN Left(THE_Value(SNO),1) = 'S';

END OPERATOR;

Ex. 5

Assume TypeX is a dictionary type. Then

TYPE TwinX POSSREP { TypeX, TypeX2 TypeX};

≡

TYPE TwinX POSSREP { TypeX TypeX, TypeX2 TypeX};

Provision is made for the same default type to be used for more than one object name by allowing several names to be specified in the same dictionary element.

Ex. 6

Dictionary;
SNO, SNO1, SNO2 CHAR;
PNO, PNO1, PNO2 CHAR;

End Dictionary;

The defined types are just SNO and PNO as in Ex 1, but the declared type names for objects named SNO1 or SNO2 can be omitted in the same manner as for objects named SNO. A similar observation applies to objects name PNO1 or PNO2.

Questions:

I know that some of these may have been answered already (after I had first drafted this posting) but I decided to leave them in for completeness.

Assume the dictionary is as defined in Ex. 6.

Q1: Regarding Ex. 4, can the RETURNS clause be omitted such that the operator’s declared type name defaults to the operator’s name?

Q2: Are the equivalencen given Ex 3-5 correct? E.g, this a legal relvar definition?

VAR S BASE REL{SNO SNO, NAME CHAR, CITY CHAR} KEY{SNO};

Q3: Is this a legal relvar definition?

VAR X BASE REL{SNO INT} KEY{SNO};

Q4: Given relvar R of heading {A INT}, is this expression legal:

R RENAME {A AS SNO}

Q5: Given relvar R of heading {A INT}, is this expression legal:

EXTEND R : {SNO := A + 1}

Q6: The database is to be extended with some new relvars and it is desired to use new dictionary types for some of the attributes. How can these additional dictionary types be added? (I assume use of INSERT on the relevant catalog relvar would be one not-very-convenient method. Right?)

Q7: Possibly a stupid question. Couldn’t system-defined scalar types be assumed to be dictionary types too? For example, couldn’t this be legal?

VAR CHAR;

If not, why not? In fact, why can’t all scalar types be dictionary types? I realise that would need a different way of specifying additional names as in Ex. 6. I also realise that expressions such as Value(Value(CHAR)), and so on ad infinitum would then be legal!

Coauthor of The Third Manifesto and related books.

#2 · May 6, 2021, 1:08 pm

Quote from Dave Voorhis on May 6, 2021, 1:08 pm

Quote from Hugh on May 6, 2021, 11:06 am

I refer to Dave Voorhis’s “dictionary” proposal that has been advanced and discussed under the rubric Tuples FTW.

In brief, he proposes a shorthand for defining a set of user-defined types that each have just a single possrep and a single possrep component. In each case the possrep name is the same as the type name and the possrep component name is Value. The purpose is much the same as that of standard SQL’s so-called distinct types: to provide a way of avoiding traps arising from inappropriate comparisons, especially ones that are implicit in operations such as joins on relations.

Here, according to my understanding, is an example, showing how it might be implemented in Rel:

Ex. 1

Dictionary;
SNO CHAR;
PNO CHAR;

End Dictionary;

As far as the type definitions are concerned this is equivalent to

Ex. 2

TYPE SNO POSSREP { Value CHAR };
TYPE PNO POSSREP { Value CHAR };

but there are two more points to the proposal. Calling those types dictionary types and their defining statements dictionary elements:

The definition of a variable with declared type a dictionary type and name the name of that type need not repeat the name. So VAR SNO; is short for VAR SNO SNO;

The same applies to declarations of objects such as attributes, parameters, and possrep components:

Ex. 3

VAR SP BASE REL{SNO, PNO, QTY INT} KEY{SNO, PNO};

≡

VAR SP BASE REL{SNO SNO, PNO PNO, QTY INT}
KEY{SNO, PNO};

Ex. 4

OPERATOR CheckSNO {SNO} RETURNS BOOLEAN;

RETURN Left(THE_Value(SNO),1) = 'S';

END OPERATOR;

≡

OPERATOR CheckSNO {SNO SNO} RETURNS BOOLEAN;

RETURN Left(THE_Value(SNO),1) = 'S';

END OPERATOR;

Ex. 5

Assume TypeX is a dictionary type. Then

TYPE TwinX POSSREP { TypeX, TypeX2 TypeX};

≡

TYPE TwinX POSSREP { TypeX TypeX, TypeX2 TypeX};

Provision is made for the same default type to be used for more than one object name by allowing several names to be specified in the same dictionary element.

Ex. 6

Dictionary;
SNO, SNO1, SNO2 CHAR;
PNO, PNO1, PNO2 CHAR;

End Dictionary;

The defined types are just SNO and PNO as in Ex 1, but the declared type names for objects named SNO1 or SNO2 can be omitted in the same manner as for objects named SNO. A similar observation applies to objects name PNO1 or PNO2.

Questions:

I know that some of these may have been answered already (after I had first drafted this posting) but I decided to leave them in for completeness.

Assume the dictionary is as defined in Ex. 6.

Q1:      Regarding Ex. 4, can the RETURNS clause be omitted such that the operator’s declared type name defaults to the operator’s name?

No. At least it's not part of what I propose.

Q2:      Are the equivalencen given Ex 3-5 correct? E.g, this a legal relvar definition?

VAR S BASE REL{SNO SNO, NAME CHAR, CITY CHAR} KEY{SNO};

Yes.

Q3:      Is this a legal relvar definition?

VAR X BASE REL{SNO INT} KEY{SNO};

Yes. Defining a dictionary entry SNO does not obligate that the only SNO be the dictionary definition. It's a distinct type from the dictionary definition's type, so type safety is preserved.

Q4:      Given relvar R of heading {A INT}, is this expression legal:

R RENAME {A AS SNO}

Yes. SNO is not forced to be globally unique(ly typed.)

Q5:      Given relvar R of heading {A INT}, is this expression legal:

EXTEND R : {SNO := A + 1}

Yes. Again, SNO is not forced to be globally unique.

Q6:      The database is to be extended with some new relvars and it is desired to use new dictionary types for some of the attributes. How can these additional dictionary types be added? (I assume use of INSERT on the relevant catalog relvar would be one not-very-convenient method. Right?)

There would be some (implementation-dependent, perhaps) mechanisms to ALTER DICTIONARY ADD <entry>, ALTER DICTIONARY DELETE <name>, etc.

Q7:      Possibly a stupid question. Couldn’t system-defined scalar types be assumed to be dictionary types too? For example, couldn’t this be legal?

VAR CHAR;

If not, why not? In fact, why can’t all scalar types be dictionary types? I realise that would need a different way of specifying additional names as in Ex. 6. I also realise that expressions such as Value(Value(CHAR)), and so on ad infinitum would then be legal!

Which is shorthand for VAR CHAR CHAR ?

I suppose it could, but it seems a curious (ab)use of the (intent of the) dictionary mechanism. Primitive built-in types are notionally special in most languages and I'd be inclined to preserve that here, if only to avoid readability issues from (mis)using it, along with practical implementation parsing issues from INT/INTEGER, CHAR/CHARACTER, RAT/RATIONAL, BOOL/BOOLEAN being reserved words. (I don't recall whether they're still reserved words in Rel or not.)

Quote from Hugh on May 6, 2021, 11:06 am

I refer to Dave Voorhis’s “dictionary” proposal that has been advanced and discussed under the rubric Tuples FTW.

In brief, he proposes a shorthand for defining a set of user-defined types that each have just a single possrep and a single possrep component. In each case the possrep name is the same as the type name and the possrep component name is Value. The purpose is much the same as that of standard SQL’s so-called distinct types: to provide a way of avoiding traps arising from inappropriate comparisons, especially ones that are implicit in operations such as joins on relations.

Here, according to my understanding, is an example, showing how it might be implemented in Rel:

Ex. 1

Dictionary;
SNO CHAR;
PNO CHAR;

End Dictionary;

As far as the type definitions are concerned this is equivalent to

Ex. 2

TYPE SNO POSSREP { Value CHAR };
TYPE PNO POSSREP { Value CHAR };

but there are two more points to the proposal. Calling those types dictionary types and their defining statements dictionary elements:

The definition of a variable with declared type a dictionary type and name the name of that type need not repeat the name. So VAR SNO; is short for VAR SNO SNO;

The same applies to declarations of objects such as attributes, parameters, and possrep components:

Ex. 3

VAR SP BASE REL{SNO, PNO, QTY INT} KEY{SNO, PNO};

≡

VAR SP BASE REL{SNO SNO, PNO PNO, QTY INT}
KEY{SNO, PNO};

Ex. 4

OPERATOR CheckSNO {SNO} RETURNS BOOLEAN;

RETURN Left(THE_Value(SNO),1) = 'S';

END OPERATOR;

≡

OPERATOR CheckSNO {SNO SNO} RETURNS BOOLEAN;

RETURN Left(THE_Value(SNO),1) = 'S';

END OPERATOR;

Ex. 5

Assume TypeX is a dictionary type. Then

TYPE TwinX POSSREP { TypeX, TypeX2 TypeX};

≡

TYPE TwinX POSSREP { TypeX TypeX, TypeX2 TypeX};

Provision is made for the same default type to be used for more than one object name by allowing several names to be specified in the same dictionary element.

Ex. 6

Dictionary;
SNO, SNO1, SNO2 CHAR;
PNO, PNO1, PNO2 CHAR;

End Dictionary;

The defined types are just SNO and PNO as in Ex 1, but the declared type names for objects named SNO1 or SNO2 can be omitted in the same manner as for objects named SNO. A similar observation applies to objects name PNO1 or PNO2.

Questions:

I know that some of these may have been answered already (after I had first drafted this posting) but I decided to leave them in for completeness.

Assume the dictionary is as defined in Ex. 6.

Q1: Regarding Ex. 4, can the RETURNS clause be omitted such that the operator’s declared type name defaults to the operator’s name?

No. At least it's not part of what I propose.

Q2: Are the equivalencen given Ex 3-5 correct? E.g, this a legal relvar definition?

VAR S BASE REL{SNO SNO, NAME CHAR, CITY CHAR} KEY{SNO};

Yes.

Q3: Is this a legal relvar definition?

VAR X BASE REL{SNO INT} KEY{SNO};

Yes. Defining a dictionary entry SNO does not obligate that the only SNO be the dictionary definition. It's a distinct type from the dictionary definition's type, so type safety is preserved.

Q4: Given relvar R of heading {A INT}, is this expression legal:

R RENAME {A AS SNO}

Yes. SNO is not forced to be globally unique(ly typed.)

Q5: Given relvar R of heading {A INT}, is this expression legal:

EXTEND R : {SNO := A + 1}

Yes. Again, SNO is not forced to be globally unique.

Q6: The database is to be extended with some new relvars and it is desired to use new dictionary types for some of the attributes. How can these additional dictionary types be added? (I assume use of INSERT on the relevant catalog relvar would be one not-very-convenient method. Right?)

There would be some (implementation-dependent, perhaps) mechanisms to ALTER DICTIONARY ADD <entry>, ALTER DICTIONARY DELETE <name>, etc.

Q7: Possibly a stupid question. Couldn’t system-defined scalar types be assumed to be dictionary types too? For example, couldn’t this be legal?

VAR CHAR;

If not, why not? In fact, why can’t all scalar types be dictionary types? I realise that would need a different way of specifying additional names as in Ex. 6. I also realise that expressions such as Value(Value(CHAR)), and so on ad infinitum would then be legal!

Which is shorthand for VAR CHAR CHAR ?

I suppose it could, but it seems a curious (ab)use of the (intent of the) dictionary mechanism. Primitive built-in types are notionally special in most languages and I'd be inclined to preserve that here, if only to avoid readability issues from (mis)using it, along with practical implementation parsing issues from INT/INTEGER, CHAR/CHARACTER, RAT/RATIONAL, BOOL/BOOLEAN being reserved words. (I don't recall whether they're still reserved words in Rel or not.)

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

#3 · May 6, 2021, 2:53 pm

When I first saw the 'dictionary' proposal, my first instinctive reaction was "that's SIRA_PRISE's ATTRIBUTE relvar" ( https://shark.armchair.mb.ca/~erwin/doc0105/public/be/SIRAPRISE/client/NAMES.RELVARNAMES.html#ATTRIBUTE , and its relvar predicate in particular). It seems like it was intended to be yet something else. The purpose of ATTRIBUTE was to have some sort of facility that, at least in the base relvars, prevents using the same (attribute) name for differently-typed things, causing/contributing to the "natural join is a disaster waiting to happen" mindset. That facility is very much "dictionary-like", which might have caused my confusion. The purpose here seems to be to offer a facility that helps the programmer avoid repetition of words in the case where he'd want the same name for a variable/attribute/... somewhere in the program and the type of that thing. I guess you'll run into that use case a lot if you're toying around/. I suspect it to be less so if what you're writing is supposed to be industrial-strength. And I believe dictionaries of business data elements are far more useful to have and exploit than dictionaries of program data types.

Author of SIRA_PRISE

#4 · May 6, 2021, 3:26 pm

Quote from Erwin on May 6, 2021, 2:53 pm

When I first saw the 'dictionary' proposal, my first instinctive reaction was "that's SIRA_PRISE's ATTRIBUTE relvar" ( https://shark.armchair.mb.ca/~erwin/doc0105/public/be/SIRAPRISE/client/NAMES.RELVARNAMES.html#ATTRIBUTE , and its relvar predicate in particular). It seems like it was intended to be yet something else. The purpose of ATTRIBUTE was to have some sort of facility that, at least in the base relvars, prevents using the same (attribute) name for differently-typed things, causing/contributing to the "natural join is a disaster waiting to happen" mindset. That facility is very much "dictionary-like", which might have caused my confusion. The purpose here seems to be to offer a facility that helps the programmer avoid repetition of words in the case where he'd want the same name for a variable/attribute/... somewhere in the program and the type of that thing. I guess you'll run into that use case a lot if you're toying around/. I suspect it to be less so if what you're writing is supposed to be industrial-strength. And I believe dictionaries of business data elements are far more useful to have and exploit than dictionaries of program data types.

The goal here is to be able to define a (say) 'CustomerID' attribute name and type, base it on an appropriate existing type like INT, and ensure that every appearance of CustomerID has the same (or a specified alternative) name and type (which facilitates proper use of natural JOIN), whilst a notionally similar 'ProductID' name/type can also based on an appropriate existing type like INT but is guaranteed to be a distinct type from CustomerID despite both being based on INT.

It's somewhat similar to 'distinct types' found in some SQL implementations. See, for example, https://www.ibm.com/docs/en/db2-warehouse?topic=types-user-defined-distinct.

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

#5 · May 6, 2021, 4:26 pm

Quote from Erwin on May 6, 2021, 4:26 pm

Quote from Dave Voorhis on May 6, 2021, 3:26 pm

Quote from Erwin on May 6, 2021, 2:53 pm

When I first saw the 'dictionary' proposal, my first instinctive reaction was "that's SIRA_PRISE's ATTRIBUTE relvar" ( https://shark.armchair.mb.ca/~erwin/doc0105/public/be/SIRAPRISE/client/NAMES.RELVARNAMES.html#ATTRIBUTE , and its relvar predicate in particular). It seems like it was intended to be yet something else. The purpose of ATTRIBUTE was to have some sort of facility that, at least in the base relvars, prevents using the same (attribute) name for differently-typed things, causing/contributing to the "natural join is a disaster waiting to happen" mindset. That facility is very much "dictionary-like", which might have caused my confusion. The purpose here seems to be to offer a facility that helps the programmer avoid repetition of words in the case where he'd want the same name for a variable/attribute/... somewhere in the program and the type of that thing. I guess you'll run into that use case a lot if you're toying around/. I suspect it to be less so if what you're writing is supposed to be industrial-strength. And I believe dictionaries of business data elements are far more useful to have and exploit than dictionaries of program data types.

The goal here is to be able to define a (say) 'CustomerID' attribute name and type, base it on an appropriate existing type like INT, and ensure that every appearance of CustomerID has the same (or a specified alternative) name and type (which facilitates proper use of natural JOIN), whilst a notionally similar 'ProductID' name/type can also based on an appropriate existing type like INT but is guaranteed to be a distinct type from CustomerID despite both being based on INT.

It's somewhat similar to 'distinct types' found in some SQL implementations. See, for example, https://www.ibm.com/docs/en/db2-warehouse?topic=types-user-defined-distinct.

OK. So the 'type' aspect is about a shorthand for declaring one-possrep, one-component types ? There's also an 'attribute' aspect, as per 'define a ... attribute name and type'. Per your examples however, there's also a 'variables' aspect because you used the idea in variable declarations. And then there's the 'dictionary' aspect which is about bundling all such declarations together in some place (and presumably be able to "import" them in some dead-easy way).

Are you sure it's a good idea to tack all of those distinct aspects onto one single language construct ?

Quote from Dave Voorhis on May 6, 2021, 3:26 pm

Quote from Erwin on May 6, 2021, 2:53 pm

When I first saw the 'dictionary' proposal, my first instinctive reaction was "that's SIRA_PRISE's ATTRIBUTE relvar" ( https://shark.armchair.mb.ca/~erwin/doc0105/public/be/SIRAPRISE/client/NAMES.RELVARNAMES.html#ATTRIBUTE , and its relvar predicate in particular). It seems like it was intended to be yet something else. The purpose of ATTRIBUTE was to have some sort of facility that, at least in the base relvars, prevents using the same (attribute) name for differently-typed things, causing/contributing to the "natural join is a disaster waiting to happen" mindset. That facility is very much "dictionary-like", which might have caused my confusion. The purpose here seems to be to offer a facility that helps the programmer avoid repetition of words in the case where he'd want the same name for a variable/attribute/... somewhere in the program and the type of that thing. I guess you'll run into that use case a lot if you're toying around/. I suspect it to be less so if what you're writing is supposed to be industrial-strength. And I believe dictionaries of business data elements are far more useful to have and exploit than dictionaries of program data types.

The goal here is to be able to define a (say) 'CustomerID' attribute name and type, base it on an appropriate existing type like INT, and ensure that every appearance of CustomerID has the same (or a specified alternative) name and type (which facilitates proper use of natural JOIN), whilst a notionally similar 'ProductID' name/type can also based on an appropriate existing type like INT but is guaranteed to be a distinct type from CustomerID despite both being based on INT.

It's somewhat similar to 'distinct types' found in some SQL implementations. See, for example, https://www.ibm.com/docs/en/db2-warehouse?topic=types-user-defined-distinct.

OK. So the 'type' aspect is about a shorthand for declaring one-possrep, one-component types ? There's also an 'attribute' aspect, as per 'define a ... attribute name and type'. Per your examples however, there's also a 'variables' aspect because you used the idea in variable declarations. And then there's the 'dictionary' aspect which is about bundling all such declarations together in some place (and presumably be able to "import" them in some dead-easy way).

Are you sure it's a good idea to tack all of those distinct aspects onto one single language construct ?

Author of SIRA_PRISE

#6 · May 6, 2021, 4:40 pm

Quote from Dave Voorhis on May 6, 2021, 4:40 pm

Quote from Erwin on May 6, 2021, 4:26 pm

Quote from Dave Voorhis on May 6, 2021, 3:26 pm

Quote from Erwin on May 6, 2021, 2:53 pm

When I first saw the 'dictionary' proposal, my first instinctive reaction was "that's SIRA_PRISE's ATTRIBUTE relvar" ( https://shark.armchair.mb.ca/~erwin/doc0105/public/be/SIRAPRISE/client/NAMES.RELVARNAMES.html#ATTRIBUTE , and its relvar predicate in particular). It seems like it was intended to be yet something else. The purpose of ATTRIBUTE was to have some sort of facility that, at least in the base relvars, prevents using the same (attribute) name for differently-typed things, causing/contributing to the "natural join is a disaster waiting to happen" mindset. That facility is very much "dictionary-like", which might have caused my confusion. The purpose here seems to be to offer a facility that helps the programmer avoid repetition of words in the case where he'd want the same name for a variable/attribute/... somewhere in the program and the type of that thing. I guess you'll run into that use case a lot if you're toying around/. I suspect it to be less so if what you're writing is supposed to be industrial-strength. And I believe dictionaries of business data elements are far more useful to have and exploit than dictionaries of program data types.

The goal here is to be able to define a (say) 'CustomerID' attribute name and type, base it on an appropriate existing type like INT, and ensure that every appearance of CustomerID has the same (or a specified alternative) name and type (which facilitates proper use of natural JOIN), whilst a notionally similar 'ProductID' name/type can also based on an appropriate existing type like INT but is guaranteed to be a distinct type from CustomerID despite both being based on INT.

It's somewhat similar to 'distinct types' found in some SQL implementations. See, for example, https://www.ibm.com/docs/en/db2-warehouse?topic=types-user-defined-distinct.

OK. So the 'type' aspect is about a shorthand for declaring one-possrep, one-component types ?

The 'type' aspect is about specially identifying (via a dictionary element) the representation for attributes/variables/parameters of a given name (or set of names), whilst ensuring that it's a unique type shared by the attributes/variables/parameters of that special identification.

The one-possrep, one-component type-shorthand is merely a means to implement it.

There's also an 'attribute' aspect, as per 'define a ... attribute name and type'. Per your examples however, there's also a 'variables' aspect because you used the idea in variable declarations. And then there's the 'dictionary' aspect which is about bundling all such declarations together in some place (and presumably be able to "import" them in some dead-easy way).

Are you sure it's a good idea to tack all of those distinct aspects onto one single language construct ?

Yes. That's what a data dictionary is for, isn't it?

Quote from Erwin on May 6, 2021, 4:26 pm

Quote from Dave Voorhis on May 6, 2021, 3:26 pm

Quote from Erwin on May 6, 2021, 2:53 pm

When I first saw the 'dictionary' proposal, my first instinctive reaction was "that's SIRA_PRISE's ATTRIBUTE relvar" ( https://shark.armchair.mb.ca/~erwin/doc0105/public/be/SIRAPRISE/client/NAMES.RELVARNAMES.html#ATTRIBUTE , and its relvar predicate in particular). It seems like it was intended to be yet something else. The purpose of ATTRIBUTE was to have some sort of facility that, at least in the base relvars, prevents using the same (attribute) name for differently-typed things, causing/contributing to the "natural join is a disaster waiting to happen" mindset. That facility is very much "dictionary-like", which might have caused my confusion. The purpose here seems to be to offer a facility that helps the programmer avoid repetition of words in the case where he'd want the same name for a variable/attribute/... somewhere in the program and the type of that thing. I guess you'll run into that use case a lot if you're toying around/. I suspect it to be less so if what you're writing is supposed to be industrial-strength. And I believe dictionaries of business data elements are far more useful to have and exploit than dictionaries of program data types.

The goal here is to be able to define a (say) 'CustomerID' attribute name and type, base it on an appropriate existing type like INT, and ensure that every appearance of CustomerID has the same (or a specified alternative) name and type (which facilitates proper use of natural JOIN), whilst a notionally similar 'ProductID' name/type can also based on an appropriate existing type like INT but is guaranteed to be a distinct type from CustomerID despite both being based on INT.

It's somewhat similar to 'distinct types' found in some SQL implementations. See, for example, https://www.ibm.com/docs/en/db2-warehouse?topic=types-user-defined-distinct.

OK. So the 'type' aspect is about a shorthand for declaring one-possrep, one-component types ?

The 'type' aspect is about specially identifying (via a dictionary element) the representation for attributes/variables/parameters of a given name (or set of names), whilst ensuring that it's a unique type shared by the attributes/variables/parameters of that special identification.

The one-possrep, one-component type-shorthand is merely a means to implement it.

There's also an 'attribute' aspect, as per 'define a ... attribute name and type'. Per your examples however, there's also a 'variables' aspect because you used the idea in variable declarations. And then there's the 'dictionary' aspect which is about bundling all such declarations together in some place (and presumably be able to "import" them in some dead-easy way).

Are you sure it's a good idea to tack all of those distinct aspects onto one single language construct ?

Yes. That's what a data dictionary is for, isn't it?

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

#7 · May 7, 2021, 12:16 am

Quote from Hugh on May 6, 2021, 11:06 am

I refer to Dave Voorhis’s “dictionary” proposal that has been advanced and discussed under the rubric Tuples FTW.

In brief, he proposes a shorthand for defining a set of user-defined types that each have just a single possrep and a single possrep component. In each case the possrep name is the same as the type name and the possrep component name is Value. The purpose is much the same as that of standard SQL’s so-called distinct types: to provide a way of avoiding traps arising from inappropriate comparisons, especially ones that are implicit in operations such as joins on relations.

On the face of it, isn't this just a type alise? Much like typedef in C? I'm a big fan, I use(d) it a lot.

But tying it into something called a 'dictionary', I'm not so sure I like that. What (extra) problem does that solve?

Andl - A New Database Language - andl.org

#8 · May 7, 2021, 8:20 am

Quote from Dave Voorhis on May 7, 2021, 8:20 am

Quote from dandl on May 7, 2021, 12:16 am

Quote from Hugh on May 6, 2021, 11:06 am

I refer to Dave Voorhis’s “dictionary” proposal that has been advanced and discussed under the rubric Tuples FTW.

In brief, he proposes a shorthand for defining a set of user-defined types that each have just a single possrep and a single possrep component. In each case the possrep name is the same as the type name and the possrep component name is Value. The purpose is much the same as that of standard SQL’s so-called distinct types: to provide a way of avoiding traps arising from inappropriate comparisons, especially ones that are implicit in operations such as joins on relations.

On the face of it, isn't this just a type alise? Much like typedef in C? I'm a big fan, I use(d) it a lot.

No, it's not a type alias.

If you write typedef qty int in C, the type names qty and int become interchangeable; they are the same type.

If you write...
DICTIONARY;
  QTY INT;
END DICTIONARY;
...per my proposal, INT and QTY are not interchangeable. Instead, a new type QTY has been implicitly created with a single POSSREP component named Value of type INT.

But tying it into something called a 'dictionary', I'm not so sure I like that. What (extra) problem does that solve?

Imagine we define a dictionary and use it like this:
DICTIONARY;
  Customer_ID INT;
  Product_ID INT;
  Quantity, OldQuantity INT;
END DICTIONARY;

VAR Customers REAL RELATION {Customer_ID} KEY {Customer_ID};
VAR Products REAL RELATION {Product_ID} KEY {Product_ID};
VAR CustomerProducts REAL RELATION {Customer_ID, Product_ID, Quantity, OldQuantity} KEY {Customer_ID, Product_ID};
As used above, the DICTIONARY provides a single point of definition (and thus a single source of truth) for all attribute names/types used in the database, and ensures that each dictionary entry is a distinct type from the others and a distinct type from INT, whilst specifying that Quantity and OldQuantity are the same type (both are type Quantity.)

The above is shorthand for:
TYPE Customer_ID POSSREP {Value INT};
TYPE Product_ID POSSREP {Value INT};
TYPE Quantity POSSREP {Value INT};

VAR Customers REAL RELATION {Customer_ID Customer_ID} KEY {Customer_ID};
VAR Products REAL RELATION {Product_ID Product_ID} KEY {Product_ID};
VAR CustomerProducts REAL RELATION {Customer_ID Customer_ID, Product_ID Product_ID, Quantity Quantity, OldQuantity Quantity} KEY {Customer_ID, Product_ID};

Quote from dandl on May 7, 2021, 12:16 am

Quote from Hugh on May 6, 2021, 11:06 am

I refer to Dave Voorhis’s “dictionary” proposal that has been advanced and discussed under the rubric Tuples FTW.

In brief, he proposes a shorthand for defining a set of user-defined types that each have just a single possrep and a single possrep component. In each case the possrep name is the same as the type name and the possrep component name is Value. The purpose is much the same as that of standard SQL’s so-called distinct types: to provide a way of avoiding traps arising from inappropriate comparisons, especially ones that are implicit in operations such as joins on relations.

On the face of it, isn't this just a type alise? Much like typedef in C? I'm a big fan, I use(d) it a lot.

No, it's not a type alias.

If you write typedef qty int in C, the type names qty and int become interchangeable; they are the same type.

If you write...

DICTIONARY;
  QTY INT;
END DICTIONARY;

...per my proposal, INT and QTY are not interchangeable. Instead, a new type QTY has been implicitly created with a single POSSREP component named Value of type INT.

But tying it into something called a 'dictionary', I'm not so sure I like that. What (extra) problem does that solve?

Imagine we define a dictionary and use it like this:

DICTIONARY;
  Customer_ID INT;
  Product_ID INT;
  Quantity, OldQuantity INT;
END DICTIONARY;

VAR Customers REAL RELATION {Customer_ID} KEY {Customer_ID};
VAR Products REAL RELATION {Product_ID} KEY {Product_ID};
VAR CustomerProducts REAL RELATION {Customer_ID, Product_ID, Quantity, OldQuantity} KEY {Customer_ID, Product_ID};

As used above, the DICTIONARY provides a single point of definition (and thus a single source of truth) for all attribute names/types used in the database, and ensures that each dictionary entry is a distinct type from the others and a distinct type from INT, whilst specifying that Quantity and OldQuantity are the same type (both are type Quantity.)

The above is shorthand for:

TYPE Customer_ID POSSREP {Value INT};
TYPE Product_ID POSSREP {Value INT};
TYPE Quantity POSSREP {Value INT};

VAR Customers REAL RELATION {Customer_ID Customer_ID} KEY {Customer_ID};
VAR Products REAL RELATION {Product_ID Product_ID} KEY {Product_ID};
VAR CustomerProducts REAL RELATION {Customer_ID Customer_ID, Product_ID Product_ID, Quantity Quantity, OldQuantity Quantity} KEY {Customer_ID, Product_ID};

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

#9 · May 7, 2021, 10:41 am

Quote from dandl on May 7, 2021, 10:41 am
Quote from Dave Voorhis on May 7, 2021, 8:20 am

Quote from dandl on May 7, 2021, 12:16 am

Quote from Hugh on May 6, 2021, 11:06 am

I refer to Dave Voorhis’s “dictionary” proposal that has been advanced and discussed under the rubric Tuples FTW.

In brief, he proposes a shorthand for defining a set of user-defined types that each have just a single possrep and a single possrep component. In each case the possrep name is the same as the type name and the possrep component name is Value. The purpose is much the same as that of standard SQL’s so-called distinct types: to provide a way of avoiding traps arising from inappropriate comparisons, especially ones that are implicit in operations such as joins on relations.

On the face of it, isn't this just a type alise? Much like typedef in C? I'm a big fan, I use(d) it a lot.

No, it's not a type alias.

If you write typedef qty int in C, the type names qty and int become interchangeable; they are the same type.

If you write...

DICTIONARY;

QTY INT;

END DICTIONARY;

DICTIONARY; QTY INT; END DICTIONARY;
DICTIONARY;
  QTY INT;
END DICTIONARY;
...per my proposal, INT and QTY are not interchangeable. Instead, a new type QTY has been implicitly created with a single POSSREP component named Value of type INT.
So this is a new blind type, with no operations, but the means to explicitly convert to and from INT?

How does that help? If for example, QTY is intended to be treated arithmetically (by referring to QTY.Value) and STATUS is not, how do you enforce that?
But tying it into something called a 'dictionary', I'm not so sure I like that. What (extra) problem does that solve?

Imagine we define a dictionary and use it like this:

DICTIONARY;

Customer_ID INT;

Product_ID INT;

Quantity, OldQuantity INT;

END DICTIONARY;

VAR Customers REAL RELATION {Customer_ID} KEY {Customer_ID};

VAR Products REAL RELATION {Product_ID} KEY {Product_ID};

VAR CustomerProducts REAL RELATION {Customer_ID, Product_ID, Quantity, OldQuantity} KEY {Customer_ID, Product_ID};

DICTIONARY; Customer_ID INT; Product_ID INT; Quantity, OldQuantity INT; END DICTIONARY; VAR Customers REAL RELATION {Customer_ID} KEY {Customer_ID}; VAR Products REAL RELATION {Product_ID} KEY {Product_ID}; VAR CustomerProducts REAL RELATION {Customer_ID, Product_ID, Quantity, OldQuantity} KEY {Customer_ID, Product_ID};
DICTIONARY;
  Customer_ID INT;
  Product_ID INT;
  Quantity, OldQuantity INT;
END DICTIONARY;

VAR Customers REAL RELATION {Customer_ID} KEY {Customer_ID};
VAR Products REAL RELATION {Product_ID} KEY {Product_ID};
VAR CustomerProducts REAL RELATION {Customer_ID, Product_ID, Quantity, OldQuantity} KEY {Customer_ID, Product_ID};
As used above, the DICTIONARY provides a single point of definition (and thus a single source of truth) for all attribute names/types used in the database, and ensures that each dictionary entry is a distinct type from the others and a distinct type from INT, whilst specifying that Quantity and OldQuantity are the same type (both are type Quantity.)
Now that's the problem. You can't define a language feature in terms of something that is not a language feature. Are you saying that (a) a dictionary is a (named?) collection of defined/declared types (b) a database (per TTM) must/should declare compliance with a particular dictionary?

Quote from Dave Voorhis on May 7, 2021, 8:20 am

Quote from dandl on May 7, 2021, 12:16 am

Quote from Hugh on May 6, 2021, 11:06 am

I refer to Dave Voorhis’s “dictionary” proposal that has been advanced and discussed under the rubric Tuples FTW.

In brief, he proposes a shorthand for defining a set of user-defined types that each have just a single possrep and a single possrep component. In each case the possrep name is the same as the type name and the possrep component name is Value. The purpose is much the same as that of standard SQL’s so-called distinct types: to provide a way of avoiding traps arising from inappropriate comparisons, especially ones that are implicit in operations such as joins on relations.

On the face of it, isn't this just a type alise? Much like typedef in C? I'm a big fan, I use(d) it a lot.

No, it's not a type alias.

If you write typedef qty int in C, the type names qty and int become interchangeable; they are the same type.

If you write...

DICTIONARY;

QTY INT;

END DICTIONARY;

DICTIONARY; QTY INT; END DICTIONARY;
DICTIONARY;
  QTY INT;
END DICTIONARY;
...per my proposal, INT and QTY are not interchangeable. Instead, a new type QTY has been implicitly created with a single POSSREP component named Value of type INT.

So this is a new blind type, with no operations, but the means to explicitly convert to and from INT?

How does that help? If for example, QTY is intended to be treated arithmetically (by referring to QTY.Value) and STATUS is not, how do you enforce that?

But tying it into something called a 'dictionary', I'm not so sure I like that. What (extra) problem does that solve?

Imagine we define a dictionary and use it like this:

DICTIONARY;

Customer_ID INT;

Product_ID INT;

Quantity, OldQuantity INT;

END DICTIONARY;

VAR Customers REAL RELATION {Customer_ID} KEY {Customer_ID};

VAR Products REAL RELATION {Product_ID} KEY {Product_ID};

VAR CustomerProducts REAL RELATION {Customer_ID, Product_ID, Quantity, OldQuantity} KEY {Customer_ID, Product_ID};

DICTIONARY; Customer_ID INT; Product_ID INT; Quantity, OldQuantity INT; END DICTIONARY; VAR Customers REAL RELATION {Customer_ID} KEY {Customer_ID}; VAR Products REAL RELATION {Product_ID} KEY {Product_ID}; VAR CustomerProducts REAL RELATION {Customer_ID, Product_ID, Quantity, OldQuantity} KEY {Customer_ID, Product_ID};
DICTIONARY;
  Customer_ID INT;
  Product_ID INT;
  Quantity, OldQuantity INT;
END DICTIONARY;

VAR Customers REAL RELATION {Customer_ID} KEY {Customer_ID};
VAR Products REAL RELATION {Product_ID} KEY {Product_ID};
VAR CustomerProducts REAL RELATION {Customer_ID, Product_ID, Quantity, OldQuantity} KEY {Customer_ID, Product_ID};
As used above, the DICTIONARY provides a single point of definition (and thus a single source of truth) for all attribute names/types used in the database, and ensures that each dictionary entry is a distinct type from the others and a distinct type from INT, whilst specifying that Quantity and OldQuantity are the same type (both are type Quantity.)

Now that's the problem. You can't define a language feature in terms of something that is not a language feature. Are you saying that (a) a dictionary is a (named?) collection of defined/declared types (b) a database (per TTM) must/should declare compliance with a particular dictionary?

Andl - A New Database Language - andl.org

#10 · May 7, 2021, 11:04 am

Quote from Dave Voorhis on May 7, 2021, 11:04 am
Quote from dandl on May 7, 2021, 10:41 am
Quote from Dave Voorhis on May 7, 2021, 8:20 am

Quote from dandl on May 7, 2021, 12:16 am

Quote from Hugh on May 6, 2021, 11:06 am

I refer to Dave Voorhis’s “dictionary” proposal that has been advanced and discussed under the rubric Tuples FTW.

In brief, he proposes a shorthand for defining a set of user-defined types that each have just a single possrep and a single possrep component. In each case the possrep name is the same as the type name and the possrep component name is Value. The purpose is much the same as that of standard SQL’s so-called distinct types: to provide a way of avoiding traps arising from inappropriate comparisons, especially ones that are implicit in operations such as joins on relations.

On the face of it, isn't this just a type alise? Much like typedef in C? I'm a big fan, I use(d) it a lot.

No, it's not a type alias.

If you write typedef qty int in C, the type names qty and int become interchangeable; they are the same type.

If you write...

DICTIONARY;

QTY INT;

END DICTIONARY;

DICTIONARY; QTY INT; END DICTIONARY;
DICTIONARY;
  QTY INT;
END DICTIONARY;
...per my proposal, INT and QTY are not interchangeable. Instead, a new type QTY has been implicitly created with a single POSSREP component named Value of type INT.
So this is a new blind type, with no operations, but the means to explicitly convert to and from INT?
I'm not sure what a "blind type" is, but the TTM writings don't specify how the selector operator and THE_Value(...) operator come into being. They might be manually authored somewhere, or they might be automatically generated. They certainly can be automatically generated and Rel does so.

How does that help? If for example, QTY is intended to be treated arithmetically (by referring to QTY.Value) and STATUS is not, how do you enforce that?

It's inherent in the fact that they are distinct types. The intent is not to prevent the user from, say, comparing THE_Value(myQTY) with THE_Value(mySTATUS) if that is desired. The intent is to prevent accidently comparing/multiplying/adding/joining/whatevering myQTY with mySTATUS because both were declared to be INT.

Take a look at some SQL implementations' "distinct types". E.g., https://www.ibm.com/docs/en/informix-servers/12.10?topic=types-distinct-data. Same idea.
But tying it into something called a 'dictionary', I'm not so sure I like that. What (extra) problem does that solve?

Imagine we define a dictionary and use it like this:

DICTIONARY;

Customer_ID INT;

Product_ID INT;

Quantity, OldQuantity INT;

END DICTIONARY;

VAR Customers REAL RELATION {Customer_ID} KEY {Customer_ID};

VAR Products REAL RELATION {Product_ID} KEY {Product_ID};

VAR CustomerProducts REAL RELATION {Customer_ID, Product_ID, Quantity, OldQuantity} KEY {Customer_ID, Product_ID};

DICTIONARY; Customer_ID INT; Product_ID INT; Quantity, OldQuantity INT; END DICTIONARY; VAR Customers REAL RELATION {Customer_ID} KEY {Customer_ID}; VAR Products REAL RELATION {Product_ID} KEY {Product_ID}; VAR CustomerProducts REAL RELATION {Customer_ID, Product_ID, Quantity, OldQuantity} KEY {Customer_ID, Product_ID};
DICTIONARY;
  Customer_ID INT;
  Product_ID INT;
  Quantity, OldQuantity INT;
END DICTIONARY;

VAR Customers REAL RELATION {Customer_ID} KEY {Customer_ID};
VAR Products REAL RELATION {Product_ID} KEY {Product_ID};
VAR CustomerProducts REAL RELATION {Customer_ID, Product_ID, Quantity, OldQuantity} KEY {Customer_ID, Product_ID};
As used above, the DICTIONARY provides a single point of definition (and thus a single source of truth) for all attribute names/types used in the database, and ensures that each dictionary entry is a distinct type from the others and a distinct type from INT, whilst specifying that Quantity and OldQuantity are the same type (both are type Quantity.)
Now that's the problem. You can't define a language feature in terms of something that is not a language feature. Are you saying that (a) a dictionary is a (named?) collection of defined/declared types (b) a database (per TTM) must/should declare compliance with a particular dictionary?
It's defined entirely in terms of existing language features, and its use is entirely optional -- all existing language features continue to work as before. You can use DICTIONARY if you wish, not use it at all if you wish, or mix use of DICTIONARY entries and the current <identifier> <type> definitions for attributes, variables, and parameters.

Quote from dandl on May 7, 2021, 10:41 am
Quote from Dave Voorhis on May 7, 2021, 8:20 am

Quote from dandl on May 7, 2021, 12:16 am

Quote from Hugh on May 6, 2021, 11:06 am

I refer to Dave Voorhis’s “dictionary” proposal that has been advanced and discussed under the rubric Tuples FTW.

In brief, he proposes a shorthand for defining a set of user-defined types that each have just a single possrep and a single possrep component. In each case the possrep name is the same as the type name and the possrep component name is Value. The purpose is much the same as that of standard SQL’s so-called distinct types: to provide a way of avoiding traps arising from inappropriate comparisons, especially ones that are implicit in operations such as joins on relations.

On the face of it, isn't this just a type alise? Much like typedef in C? I'm a big fan, I use(d) it a lot.

No, it's not a type alias.

If you write typedef qty int in C, the type names qty and int become interchangeable; they are the same type.

If you write...

DICTIONARY;

QTY INT;

END DICTIONARY;

DICTIONARY; QTY INT; END DICTIONARY;
DICTIONARY;
  QTY INT;
END DICTIONARY;
...per my proposal, INT and QTY are not interchangeable. Instead, a new type QTY has been implicitly created with a single POSSREP component named Value of type INT.
So this is a new blind type, with no operations, but the means to explicitly convert to and from INT?

I'm not sure what a "blind type" is, but the TTM writings don't specify how the selector operator and THE_Value(...) operator come into being. They might be manually authored somewhere, or they might be automatically generated. They certainly can be automatically generated and Rel does so.

How does that help? If for example, QTY is intended to be treated arithmetically (by referring to QTY.Value) and STATUS is not, how do you enforce that?

It's inherent in the fact that they are distinct types. The intent is not to prevent the user from, say, comparing THE_Value(myQTY) with THE_Value(mySTATUS) if that is desired. The intent is to prevent accidently comparing/multiplying/adding/joining/whatevering myQTY with mySTATUS because both were declared to be INT.

Take a look at some SQL implementations' "distinct types". E.g., https://www.ibm.com/docs/en/informix-servers/12.10?topic=types-distinct-data. Same idea.

But tying it into something called a 'dictionary', I'm not so sure I like that. What (extra) problem does that solve?

Imagine we define a dictionary and use it like this:

DICTIONARY;

Customer_ID INT;

Product_ID INT;

Quantity, OldQuantity INT;

END DICTIONARY;

VAR Customers REAL RELATION {Customer_ID} KEY {Customer_ID};

VAR Products REAL RELATION {Product_ID} KEY {Product_ID};

VAR CustomerProducts REAL RELATION {Customer_ID, Product_ID, Quantity, OldQuantity} KEY {Customer_ID, Product_ID};

DICTIONARY; Customer_ID INT; Product_ID INT; Quantity, OldQuantity INT; END DICTIONARY; VAR Customers REAL RELATION {Customer_ID} KEY {Customer_ID}; VAR Products REAL RELATION {Product_ID} KEY {Product_ID}; VAR CustomerProducts REAL RELATION {Customer_ID, Product_ID, Quantity, OldQuantity} KEY {Customer_ID, Product_ID};
DICTIONARY;
  Customer_ID INT;
  Product_ID INT;
  Quantity, OldQuantity INT;
END DICTIONARY;

VAR Customers REAL RELATION {Customer_ID} KEY {Customer_ID};
VAR Products REAL RELATION {Product_ID} KEY {Product_ID};
VAR CustomerProducts REAL RELATION {Customer_ID, Product_ID, Quantity, OldQuantity} KEY {Customer_ID, Product_ID};
As used above, the DICTIONARY provides a single point of definition (and thus a single source of truth) for all attribute names/types used in the database, and ensures that each dictionary entry is a distinct type from the others and a distinct type from INT, whilst specifying that Quantity and OldQuantity are the same type (both are type Quantity.)
Now that's the problem. You can't define a language feature in terms of something that is not a language feature. Are you saying that (a) a dictionary is a (named?) collection of defined/declared types (b) a database (per TTM) must/should declare compliance with a particular dictionary?

It's defined entirely in terms of existing language features, and its use is entirely optional -- all existing language features continue to work as before. You can use DICTIONARY if you wish, not use it at all if you wish, or mix use of DICTIONARY entries and the current <identifier> <type> definitions for attributes, variables, and parameters.

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

The Forum for Discussion about The Third Manifesto and Related Matters

Dictionaries