The Third Manifesto ForumThe Third Manifesto: TTM General discussionFirst and second class citizens i …

Please or Register to create posts and topics.

First and second class citizens in TTM

#41 · June 11, 2019, 2:57 pm

Quote from Dave Voorhis on June 11, 2019, 2:57 pm

Quote from dandl on June 11, 2019, 2:35 pm

Quote from Hugh on June 11, 2019, 10:40 am

Dave Voorhis is absolutely right in noting that the only scalar type that TTM mandates is BOOLEAN. (It also mandates tuple and relation types, of course.) Imagining a D that has no numeric types might not be too difficult, he surmises, but I note that, for example, Tutorial D's COUNT operator would not be available as defined. My favourite programming language, Rexx (because it's (a) fun and (b) particularly useful for most of the coding I've had or chosen to do since the mid-1980s), doesn't have numeric types but supports numerical operators on character strings, returning character strings, an approach that works fine for my purposes.

Our reason for mandating BOOLEAN was to correct what we retrospectively regarded as an omission by Codd, and our reason for not mandating any other scalar types was to emphasise the neutrality of the RM with respect to scalar types. We didn't consider it our business to prescribe or even very strongly suggest which others should be supported.

Hugh

Your point is correct of course. I merely proposed that a D is likely to need numeric and character types because those types or objects of those types are mentioned in TTM. But as you say, it's perfectly possible to have a very substantial language with only a single data type, either integer or character. I've used examples of both. TCL anyone?

So while we might know of a stripped down language with only a single non-boolean type, the type system is at the heart of TTM and I find it hard to imagine a D that satisfies all of TTM without a rich type system. And how could one have a rich type system and yet somehow omit numeric and character types?

At risk of being accused of taking liberties with the definition of what is generally considered to be part of a language or not, I suggest that a general-purpose D might not define numeric and character types as part of the language itself. Indeed, the language itself might be very minimal.

Numeric, character, other types, and even perhaps most of the relational operators and special operators like COUNT() -- which returns a numeric value -- etc., would be part of that language's standard library, but not the language itself.

Quote from dandl on June 11, 2019, 2:35 pm

Quote from Hugh on June 11, 2019, 10:40 am

Dave Voorhis is absolutely right in noting that the only scalar type that TTM mandates is BOOLEAN. (It also mandates tuple and relation types, of course.) Imagining a D that has no numeric types might not be too difficult, he surmises, but I note that, for example, Tutorial D's COUNT operator would not be available as defined. My favourite programming language, Rexx (because it's (a) fun and (b) particularly useful for most of the coding I've had or chosen to do since the mid-1980s), doesn't have numeric types but supports numerical operators on character strings, returning character strings, an approach that works fine for my purposes.

Our reason for mandating BOOLEAN was to correct what we retrospectively regarded as an omission by Codd, and our reason for not mandating any other scalar types was to emphasise the neutrality of the RM with respect to scalar types. We didn't consider it our business to prescribe or even very strongly suggest which others should be supported.

Hugh

Your point is correct of course. I merely proposed that a D is likely to need numeric and character types because those types or objects of those types are mentioned in TTM. But as you say, it's perfectly possible to have a very substantial language with only a single data type, either integer or character. I've used examples of both. TCL anyone?

So while we might know of a stripped down language with only a single non-boolean type, the type system is at the heart of TTM and I find it hard to imagine a D that satisfies all of TTM without a rich type system. And how could one have a rich type system and yet somehow omit numeric and character types?

At risk of being accused of taking liberties with the definition of what is generally considered to be part of a language or not, I suggest that a general-purpose D might not define numeric and character types as part of the language itself. Indeed, the language itself might be very minimal.

Numeric, character, other types, and even perhaps most of the relational operators and special operators like COUNT() -- which returns a numeric value -- etc., would be part of that language's standard library, but not the language itself.

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

#42 · June 11, 2019, 2:57 pm

Quote from AntC on June 11, 2019, 2:05 pm

Quote from Hugh on June 11, 2019, 10:40 am

Our reason for mandating BOOLEAN was to correct what we retrospectively regarded as an omission by Codd, ...

Thanks Hugh, which particular omission was that? (I ask because I can think of several.)

Mandating BOOLEAN is indeed sensible in practice; but in theory ...

RM Pre 1 for BOOLEAN prescribes "D shall support all four monadic and 16 dyadic logical operators, directly or indirectly, for this type." Then we could mimic Boolean operators using DUM, DEE as the values and traditional relational operators for all the logic you might need.

TTM prescribes BOOLEAN types to describe the results of evaluating integrity constraints (RM Pre 23). Typical practice (in Tutorial D) is that the formula for an integrity constraint is of the form IS_EMPTY( ... ).

We'd want DEE to correspond to TRUE, so the equivalent of IS_EMPTY( ... ) in constraints would be DEE NOT MATCHING ( ... ).

It's not very clear (IIRC from Chris's analysis of Codd's early papers) whether Codd omitted degree zero relations; or whether he anticipated them but suppressed that thought because it would cause conniptions amongst IBM engineers and top brass(?)

But DEE and DUM (which Codd also omitted and in fact deprecated, asking, "What are they for?") aren't truth values. We certainly wouldn't wouldn't want a D to be "mimicking" BOOLEAN with relation types. Besides, what about x = y? TTM requires support for "=" as defined.

Hugh

Coauthor of The Third Manifesto and related books.

#43 · June 22, 2019, 6:23 am

Quote from AntC on June 22, 2019, 6:23 am

Quote from Hugh on June 11, 2019, 2:57 pm

Quote from AntC on June 11, 2019, 2:05 pm

Quote from Hugh on June 11, 2019, 10:40 am

Our reason for mandating BOOLEAN was to correct what we retrospectively regarded as an omission by Codd, ...

Mandating BOOLEAN is indeed sensible in practice; but in theory ...

RM Pre 1 for BOOLEAN prescribes "D shall support all four monadic and 16 dyadic logical operators, directly or indirectly, for this type." Then we could mimic Boolean operators using DUM, DEE as the values and traditional relational operators for all the logic you might need.

TTM prescribes BOOLEAN types to describe the results of evaluating integrity constraints (RM Pre 23). Typical practice (in Tutorial D) is that the formula for an integrity constraint is of the form IS_EMPTY( ... ).

We'd want DEE to correspond to TRUE, so the equivalent of IS_EMPTY( ... ) in constraints would be DEE NOT MATCHING ( ... ).

It's not very clear (IIRC from Chris's analysis of Codd's early papers) whether Codd omitted degree zero relations; or whether he anticipated them but suppressed that thought because it would cause conniptions amongst IBM engineers and top brass(?)

But DEE and DUM (which Codd also omitted and in fact deprecated, asking, "What are they for?") aren't truth values.

There's that slippery verb ' to be' again. I think you're failing to distinguish abstrep (a logical/abstract truth value) vs possrep (its representation in some D).

I wonder ... As well as Tutorial D and the fabled Industrial D, there might be Algebraical D.

The only values are relations; the only operations take relations as operands, return relations as result.

The possrep for a tuple is a singleton relation. The possrep for a scalar is a singleton relation of degree one.

We certainly wouldn't wouldn't want a D to be "mimicking" BOOLEAN with relation types.

Why on earth not? The algebra of relations is a superset of a Boolean algebra. JOIN corresponds to AND; UNION corresponds to OR; NOTMATCHING corresponds to ANDNOT. My "mimic" was a possibly sloppy term: let's say "represent" as in "possible representation".

Besides, what about x = y? TTM requires support for "=" as defined.

Of course there's support for equality-testing between relations [**]. Equality-testing between scalars (i.e. singleton relations of degree one) corresponds thusly:

x == y =_df (REL{TUP{XY x}} JOIN REL{TUP{XY y}}) {}

Oops, that trailing {} for projection to degree zero isn't a relational operator taking only relations as operands. I mean ... InnerUnion DUM.

[Note **] where equality of relations

r1 == r2 =_df (DEE NOTMATCHING ((r1 NOTMATCHING r2) InnerUnion (r2 NOTMATCHING r1)))

Quote from Hugh on June 11, 2019, 2:57 pm

Quote from AntC on June 11, 2019, 2:05 pm

Quote from Hugh on June 11, 2019, 10:40 am

Our reason for mandating BOOLEAN was to correct what we retrospectively regarded as an omission by Codd, ...

Mandating BOOLEAN is indeed sensible in practice; but in theory ...

RM Pre 1 for BOOLEAN prescribes "D shall support all four monadic and 16 dyadic logical operators, directly or indirectly, for this type." Then we could mimic Boolean operators using DUM, DEE as the values and traditional relational operators for all the logic you might need.

TTM prescribes BOOLEAN types to describe the results of evaluating integrity constraints (RM Pre 23). Typical practice (in Tutorial D) is that the formula for an integrity constraint is of the form IS_EMPTY( ... ).

We'd want DEE to correspond to TRUE, so the equivalent of IS_EMPTY( ... ) in constraints would be DEE NOT MATCHING ( ... ).

It's not very clear (IIRC from Chris's analysis of Codd's early papers) whether Codd omitted degree zero relations; or whether he anticipated them but suppressed that thought because it would cause conniptions amongst IBM engineers and top brass(?)

But DEE and DUM (which Codd also omitted and in fact deprecated, asking, "What are they for?") aren't truth values.

There's that slippery verb ' to be' again. I think you're failing to distinguish abstrep (a logical/abstract truth value) vs possrep (its representation in some D).

I wonder ... As well as Tutorial D and the fabled Industrial D, there might be Algebraical D.

The only values are relations; the only operations take relations as operands, return relations as result.

The possrep for a tuple is a singleton relation. The possrep for a scalar is a singleton relation of degree one.

We certainly wouldn't wouldn't want a D to be "mimicking" BOOLEAN with relation types.

Why on earth not? The algebra of relations is a superset of a Boolean algebra. JOIN corresponds to AND; UNION corresponds to OR; NOTMATCHING corresponds to ANDNOT. My "mimic" was a possibly sloppy term: let's say "represent" as in "possible representation".

Besides, what about x = y? TTM requires support for "=" as defined.

Of course there's support for equality-testing between relations [**]. Equality-testing between scalars (i.e. singleton relations of degree one) corresponds thusly:

x == y =_df (REL{TUP{XY x}} JOIN REL{TUP{XY y}}) {}

Oops, that trailing {} for projection to degree zero isn't a relational operator taking only relations as operands. I mean ... InnerUnion DUM.

[Note **] where equality of relations

r1 == r2 =_df (DEE NOTMATCHING ((r1 NOTMATCHING r2) InnerUnion (r2 NOTMATCHING r1)))

#44 · June 22, 2019, 1:14 pm

Quote from johnwcowan on June 22, 2019, 1:14 pm

Quote from AntC on June 22, 2019, 6:23 am

I wonder ... As well as Tutorial D and the fabled Industrial D, there might be Algebraical D.

The only values are relations; the only operations take relations as operands, return relations as result.

The possrep for a tuple is a singleton relation. The possrep for a scalar is a singleton relation of degree one.

I really like this idea as you have laid it out! For a practical language, though, you'd need some way of distinguishing scalars from non-scalars, and of representing numbers, rationals, and strings uniquely. I don't think there's any actual need even in D to distinguish tuples from relations of cardinality 1, any more than there is a need to distinguish strings of length 1 from other strings. With some primitive strings (there are exactly 1112064 of them, which will suffice till we meet the Galactic Empire) and the generating function ||, we can generate all strings, just as with the single primitive natural number 0 and the generating function Succ, we can generate all natural numbers.

I think the simplest approach is to have some reserved attribute names. Thus a scalar can be a relation of cardinality 1 whose sole attribute is named σ (for scalar), which distinguishes it from any other relation with degree and cardinality 1. Then we need representations of integers, rationals, and strings. I think the simplest way to represent an integer is as a relation with the sole boolean attribute ι whose cardinality is the absolute value of the integer. If its tuples are all {DEE}, it is positive; if they are all {DUM}, it is negative; if there are no tuples, it is 0. From that rational numbers come immediately as a relation of cardinality 1 whose integer attributes are named ν (numerator) and δ (denominator).

It would be possible to represent strings using Gödel numbering, or even a simplified Gödel numbering in which the string is the sum of the Unicode value of each character times 1114112 to the power of its zero-based index. But that is dire and counterintuitive. It is simpler to have relations with two integer attributes[*], υ for the Unicode scalar value, and ξ for the index (probably one-based in this case).

[*] Assuming this is legal in your country.

Quote from AntC on June 22, 2019, 6:23 am

I wonder ... As well as Tutorial D and the fabled Industrial D, there might be Algebraical D.

The only values are relations; the only operations take relations as operands, return relations as result.

The possrep for a tuple is a singleton relation. The possrep for a scalar is a singleton relation of degree one.

I really like this idea as you have laid it out! For a practical language, though, you'd need some way of distinguishing scalars from non-scalars, and of representing numbers, rationals, and strings uniquely. I don't think there's any actual need even in D to distinguish tuples from relations of cardinality 1, any more than there is a need to distinguish strings of length 1 from other strings. With some primitive strings (there are exactly 1112064 of them, which will suffice till we meet the Galactic Empire) and the generating function ||, we can generate all strings, just as with the single primitive natural number 0 and the generating function Succ, we can generate all natural numbers.

I think the simplest approach is to have some reserved attribute names. Thus a scalar can be a relation of cardinality 1 whose sole attribute is named σ (for scalar), which distinguishes it from any other relation with degree and cardinality 1. Then we need representations of integers, rationals, and strings. I think the simplest way to represent an integer is as a relation with the sole boolean attribute ι whose cardinality is the absolute value of the integer. If its tuples are all {DEE}, it is positive; if they are all {DUM}, it is negative; if there are no tuples, it is 0. From that rational numbers come immediately as a relation of cardinality 1 whose integer attributes are named ν (numerator) and δ (denominator).

It would be possible to represent strings using Gödel numbering, or even a simplified Gödel numbering in which the string is the sum of the Unicode value of each character times 1114112 to the power of its zero-based index. But that is dire and counterintuitive. It is simpler to have relations with two integer attributes[*], υ for the Unicode scalar value, and ξ for the index (probably one-based in this case).

[*] Assuming this is legal in your country.

#45 · June 22, 2019, 4:20 pm

Quote from Hugh on June 22, 2019, 4:20 pm

Quote from AntC on June 22, 2019, 6:23 am

Quote from Hugh on June 11, 2019, 2:57 pm

Quote from AntC on June 11, 2019, 2:05 pm

Quote from Hugh on June 11, 2019, 10:40 am

Our reason for mandating BOOLEAN was to correct what we retrospectively regarded as an omission by Codd, ...

Mandating BOOLEAN is indeed sensible in practice; but in theory ...

RM Pre 1 for BOOLEAN prescribes "D shall support all four monadic and 16 dyadic logical operators, directly or indirectly, for this type." Then we could mimic Boolean operators using DUM, DEE as the values and traditional relational operators for all the logic you might need.

TTM prescribes BOOLEAN types to describe the results of evaluating integrity constraints (RM Pre 23). Typical practice (in Tutorial D) is that the formula for an integrity constraint is of the form IS_EMPTY( ... ).

We'd want DEE to correspond to TRUE, so the equivalent of IS_EMPTY( ... ) in constraints would be DEE NOT MATCHING ( ... ).

It's not very clear (IIRC from Chris's analysis of Codd's early papers) whether Codd omitted degree zero relations; or whether he anticipated them but suppressed that thought because it would cause conniptions amongst IBM engineers and top brass(?)

But DEE and DUM (which Codd also omitted and in fact deprecated, asking, "What are they for?") aren't truth values.

There's that slippery verb ' to be' again. I think you're failing to distinguish abstrep (a logical/abstract truth value) vs possrep (its representation in some D).

I think I can reasonably claim to understand that distinction quite well. A possrep is a syntactical device to define several necessary operators in one fell swoop. Antc's comment seems to be suggesting that 0-adic relations be used as possrep components for type BOOLEAN. All right then, the user-defined scalar type definition would look like this:

TYPE BOOLEAN POSSREP {DEEDUM RELATION{}};

And if BOOLEAN is not system-defined, users would be required under TTM to give such a definition.

But TTM also requires support for truth-valued equality comparisons, so "=" would have to be user-defined too. And it has to be available for value-pairs of every type. I'm prepared to be convinced that a generic signature might be possible, but what about the implementation. How can I write a RETURN statement that returns BOOLEAN(TABLE_DEE) if the operands are the selfsame value, otherwise BOOLEAN(TABLE_DUM)?

I note in passing that TRUE and FALSE could be user-defined operators: OPERATOR TRUE ( ) RETURNS BOOLEAN; RETURN BOOLEAN(TABLE_DEE); END OPERATOR, and likewise FALSE(), and the language might permit parens to be omitted in niladic operator invocations.

Hugh

Quote from AntC on June 22, 2019, 6:23 am

Quote from Hugh on June 11, 2019, 2:57 pm

Quote from AntC on June 11, 2019, 2:05 pm

Quote from Hugh on June 11, 2019, 10:40 am

Our reason for mandating BOOLEAN was to correct what we retrospectively regarded as an omission by Codd, ...

Mandating BOOLEAN is indeed sensible in practice; but in theory ...

RM Pre 1 for BOOLEAN prescribes "D shall support all four monadic and 16 dyadic logical operators, directly or indirectly, for this type." Then we could mimic Boolean operators using DUM, DEE as the values and traditional relational operators for all the logic you might need.

TTM prescribes BOOLEAN types to describe the results of evaluating integrity constraints (RM Pre 23). Typical practice (in Tutorial D) is that the formula for an integrity constraint is of the form IS_EMPTY( ... ).

We'd want DEE to correspond to TRUE, so the equivalent of IS_EMPTY( ... ) in constraints would be DEE NOT MATCHING ( ... ).

It's not very clear (IIRC from Chris's analysis of Codd's early papers) whether Codd omitted degree zero relations; or whether he anticipated them but suppressed that thought because it would cause conniptions amongst IBM engineers and top brass(?)

But DEE and DUM (which Codd also omitted and in fact deprecated, asking, "What are they for?") aren't truth values.

There's that slippery verb ' to be' again. I think you're failing to distinguish abstrep (a logical/abstract truth value) vs possrep (its representation in some D).

I think I can reasonably claim to understand that distinction quite well. A possrep is a syntactical device to define several necessary operators in one fell swoop. Antc's comment seems to be suggesting that 0-adic relations be used as possrep components for type BOOLEAN. All right then, the user-defined scalar type definition would look like this:

TYPE BOOLEAN POSSREP {DEEDUM RELATION{}};

And if BOOLEAN is not system-defined, users would be required under TTM to give such a definition.

But TTM also requires support for truth-valued equality comparisons, so "=" would have to be user-defined too. And it has to be available for value-pairs of every type. I'm prepared to be convinced that a generic signature might be possible, but what about the implementation. How can I write a RETURN statement that returns BOOLEAN(TABLE_DEE) if the operands are the selfsame value, otherwise BOOLEAN(TABLE_DUM)?

I note in passing that TRUE and FALSE could be user-defined operators: OPERATOR TRUE ( ) RETURNS BOOLEAN; RETURN BOOLEAN(TABLE_DEE); END OPERATOR, and likewise FALSE(), and the language might permit parens to be omitted in niladic operator invocations.

Hugh

Coauthor of The Third Manifesto and related books.

#46 · June 23, 2019, 12:28 am

Quote from AntC on June 23, 2019, 12:28 am

Quote from johnwcowan on June 22, 2019, 1:14 pm

Quote from AntC on June 22, 2019, 6:23 am

I wonder ... As well as Tutorial D and the fabled Industrial D, there might be Algebraical D.

The only values are relations; the only operations take relations as operands, return relations as result.

The possrep for a tuple is a singleton relation. The possrep for a scalar is a singleton relation of degree one.

I really like this idea as you have laid it out!

Uh oh. You're getting carried away. Algebraical D is certainly not a "practical language" -- as I said up-thread.

For a practical language, though, you'd need some way of distinguishing scalars from non-scalars,

No: "The only values are relations." You can distinguish/constrain relations of cardinality one/degree one using relational operators.

and of representing numbers, rationals, and strings uniquely. I don't think there's any actual need even in D to distinguish tuples from relations of cardinality 1, any more than there is a need to distinguish strings of length 1 from other strings. With some primitive strings (there are exactly 1112064 of them, which will suffice till we meet the Galactic Empire) and the generating function ||, we can generate all strings, just as with the single primitive natural number 0 and the generating function Succ, we can generate all natural numbers.

I think the simplest approach is to have some reserved attribute names.

No: If you're comparing two relations of cardinalityonedegreeone, those are presumably restrictions/projections of fuller relations, which already come with attribute names. (You might need a RENAME.)

Thus a scalar can be a relation of cardinality 1 whose sole attribute is named σ (for scalar), which distinguishes it from any other relation with degree and cardinality 1. Then we need representations of integers, rationals, and strings.

I'll separate out the following part, because it betrays a huge confusion:

I think the simplest way to represent an integer is as a relation with the sole boolean attribute ι whose cardinality is the absolute value of the integer.

A relation (value) is a set. If you want a relation of cardinality n you need to find n distinct values (or combos of values to go into a tuple). I suggest the easiest way to get a relation of cardinality n is to fill its attribute with integers from 1 to n. (I'm not quite enough of an algebraist to start at zero.) Is this going round in circles? Yes.

If its tuples are all {DEE},

DEE is a relation (value). What are the { } braces to indicate? So you mean the tuples have a single attribute named ι with value DEE? You mean the tuples contain a relation valued attribute? If some relation value (you're claiming to represent an integer) has "tuples ... all" the same value, then it contains exactly one tuple. Same applies if your tuples contain RVA value DUM.

You could possibly represent zero as RVA DUM, 1 as RVA DEE, 2 as RVA REL{TUP{ι REL{TUP{ι DEE}}}} and in general n+1 as RVA REL{TUP{ι rvan}} in which rvan is the RVA representing n. But in TTM terms you now have attribute values of different type, so they're not comparable (and you need something like the Inheritance Model to even put them in the same relation).

it is positive; if they are all {DUM}, it is negative; if there are no tuples, it is 0. From that rational numbers come immediately as a relation of cardinality 1 whose integer attributes are named ν (numerator) and δ (denominator).

It would be possible to represent strings using Gödel numbering, or even a simplified Gödel numbering in which the string is the sum of the Unicode value of each character times 1114112 to the power of its zero-based index. But that is dire and counterintuitive. It is simpler to have relations with two integer attributes[*], υ for the Unicode scalar value, and ξ for the index (probably one-based in this case).

[*] Assuming this is legal in your country.

The algebraist is supremely unconcerned about the contents of your relation values. For the algebra, relation values are uninterpreted, and attribute type(s)/values are orthogonal to model. We assume a supply of relations-as-operators, per Appendix A PLUS that you JOIN/COMPOSE to achieve the typical calculations.

Quote from johnwcowan on June 22, 2019, 1:14 pm

Quote from AntC on June 22, 2019, 6:23 am

I wonder ... As well as Tutorial D and the fabled Industrial D, there might be Algebraical D.

The only values are relations; the only operations take relations as operands, return relations as result.

The possrep for a tuple is a singleton relation. The possrep for a scalar is a singleton relation of degree one.

I really like this idea as you have laid it out!

Uh oh. You're getting carried away. Algebraical D is certainly not a "practical language" -- as I said up-thread.

For a practical language, though, you'd need some way of distinguishing scalars from non-scalars,

No: "The only values are relations." You can distinguish/constrain relations of cardinality one/degree one using relational operators.

and of representing numbers, rationals, and strings uniquely. I don't think there's any actual need even in D to distinguish tuples from relations of cardinality 1, any more than there is a need to distinguish strings of length 1 from other strings. With some primitive strings (there are exactly 1112064 of them, which will suffice till we meet the Galactic Empire) and the generating function ||, we can generate all strings, just as with the single primitive natural number 0 and the generating function Succ, we can generate all natural numbers.

I think the simplest approach is to have some reserved attribute names.

No: If you're comparing two relations of cardinalityonedegreeone, those are presumably restrictions/projections of fuller relations, which already come with attribute names. (You might need a RENAME.)

Thus a scalar can be a relation of cardinality 1 whose sole attribute is named σ (for scalar), which distinguishes it from any other relation with degree and cardinality 1. Then we need representations of integers, rationals, and strings.

I'll separate out the following part, because it betrays a huge confusion:

I think the simplest way to represent an integer is as a relation with the sole boolean attribute ι whose cardinality is the absolute value of the integer.

A relation (value) is a set. If you want a relation of cardinality n you need to find n distinct values (or combos of values to go into a tuple). I suggest the easiest way to get a relation of cardinality n is to fill its attribute with integers from 1 to n. (I'm not quite enough of an algebraist to start at zero.) Is this going round in circles? Yes.

If its tuples are all {DEE},

DEE is a relation (value). What are the { } braces to indicate? So you mean the tuples have a single attribute named ι with value DEE? You mean the tuples contain a relation valued attribute? If some relation value (you're claiming to represent an integer) has "tuples ... all" the same value, then it contains exactly one tuple. Same applies if your tuples contain RVA value DUM.

You could possibly represent zero as RVA DUM, 1 as RVA DEE, 2 as RVA REL{TUP{ι REL{TUP{ι DEE}}}} and in general n+1 as RVA REL{TUP{ι rvan}} in which rvan is the RVA representing n. But in TTM terms you now have attribute values of different type, so they're not comparable (and you need something like the Inheritance Model to even put them in the same relation).

it is positive; if they are all {DUM}, it is negative; if there are no tuples, it is 0. From that rational numbers come immediately as a relation of cardinality 1 whose integer attributes are named ν (numerator) and δ (denominator).

It would be possible to represent strings using Gödel numbering, or even a simplified Gödel numbering in which the string is the sum of the Unicode value of each character times 1114112 to the power of its zero-based index. But that is dire and counterintuitive. It is simpler to have relations with two integer attributes[*], υ for the Unicode scalar value, and ξ for the index (probably one-based in this case).

[*] Assuming this is legal in your country.

The algebraist is supremely unconcerned about the contents of your relation values. For the algebra, relation values are uninterpreted, and attribute type(s)/values are orthogonal to model. We assume a supply of relations-as-operators, per Appendix A PLUS that you JOIN/COMPOSE to achieve the typical calculations.

#47 · June 23, 2019, 12:59 am

Quote from AntC on June 23, 2019, 12:59 am

Quote from Hugh on June 22, 2019, 4:20 pm

Quote from AntC on June 22, 2019, 6:23 am

Quote from Hugh on June 11, 2019, 2:57 pm

Quote from AntC on June 11, 2019, 2:05 pm

Quote from Hugh on June 11, 2019, 10:40 am

Our reason for mandating BOOLEAN was to correct what we retrospectively regarded as an omission by Codd, ...

Mandating BOOLEAN is indeed sensible in practice; but in theory ...

RM Pre 1 for BOOLEAN prescribes "D shall support all four monadic and 16 dyadic logical operators, directly or indirectly, for this type." Then we could mimic Boolean operators using DUM, DEE as the values and traditional relational operators for all the logic you might need.

TTM prescribes BOOLEAN types to describe the results of evaluating integrity constraints (RM Pre 23). Typical practice (in Tutorial D) is that the formula for an integrity constraint is of the form IS_EMPTY( ... ).

We'd want DEE to correspond to TRUE, so the equivalent of IS_EMPTY( ... ) in constraints would be DEE NOT MATCHING ( ... ).

It's not very clear (IIRC from Chris's analysis of Codd's early papers) whether Codd omitted degree zero relations; or whether he anticipated them but suppressed that thought because it would cause conniptions amongst IBM engineers and top brass(?)

But DEE and DUM (which Codd also omitted and in fact deprecated, asking, "What are they for?") aren't truth values.

There's that slippery verb ' to be' again. I think you're failing to distinguish abstrep (a logical/abstract truth value) vs possrep (its representation in some D).

I think I can reasonably claim to understand that distinction quite well. A possrep is a syntactical device to define several necessary operators in one fell swoop. Antc's comment seems to be suggesting that 0-adic relations be used as possrep components for type BOOLEAN. All right then, the user-defined scalar type definition would look like this:

TYPE BOOLEAN POSSREP {DEEDUM RELATION{}};

No, there's no need to define a distinct type to represent BOOLEAN. You could use "BOOLEAN" as a typename alias (that Tutorial D does not have, see other discussions) to denote values of type RELATION constrained to degree zero.

And if BOOLEAN is not system-defined, users would be required under TTM to give such a definition.

But TTM also requires support for truth-valued equality comparisons, so "=" would have to be user-defined too.

You're repeating the point from an earlier message, and that I rather think I answered comprehensively. If everything is a relation (and the the possrep for scalar values is a relation of cardinality one degree one), then you already have scalar equality comparison: it's spelled JOIN (result projected on to degree zero).

And it has to be available for value-pairs of every type. I'm prepared to be convinced that a generic signature might be possible, but what about the implementation. How can I write a RETURN statement that returns BOOLEAN(TABLE_DEE) if the operands are the selfsame value, otherwise BOOLEAN(TABLE_DUM)?

I note in passing that TRUE and FALSE could be user-defined operators: OPERATOR TRUE ( ) RETURNS BOOLEAN; RETURN BOOLEAN(TABLE_DEE); END OPERATOR, and likewise FALSE(), and the language might permit parens to be omitted in niladic operator invocations.

TRUE, FALSE could be aliases for values DEE, DUM. Not operators, not variables: what some languages call "manifest constants".

Quote from Hugh on June 22, 2019, 4:20 pm

Quote from AntC on June 22, 2019, 6:23 am

Quote from Hugh on June 11, 2019, 2:57 pm

Quote from AntC on June 11, 2019, 2:05 pm

Quote from Hugh on June 11, 2019, 10:40 am

Our reason for mandating BOOLEAN was to correct what we retrospectively regarded as an omission by Codd, ...

Mandating BOOLEAN is indeed sensible in practice; but in theory ...

RM Pre 1 for BOOLEAN prescribes "D shall support all four monadic and 16 dyadic logical operators, directly or indirectly, for this type." Then we could mimic Boolean operators using DUM, DEE as the values and traditional relational operators for all the logic you might need.

TTM prescribes BOOLEAN types to describe the results of evaluating integrity constraints (RM Pre 23). Typical practice (in Tutorial D) is that the formula for an integrity constraint is of the form IS_EMPTY( ... ).

We'd want DEE to correspond to TRUE, so the equivalent of IS_EMPTY( ... ) in constraints would be DEE NOT MATCHING ( ... ).

It's not very clear (IIRC from Chris's analysis of Codd's early papers) whether Codd omitted degree zero relations; or whether he anticipated them but suppressed that thought because it would cause conniptions amongst IBM engineers and top brass(?)

But DEE and DUM (which Codd also omitted and in fact deprecated, asking, "What are they for?") aren't truth values.

There's that slippery verb ' to be' again. I think you're failing to distinguish abstrep (a logical/abstract truth value) vs possrep (its representation in some D).

I think I can reasonably claim to understand that distinction quite well. A possrep is a syntactical device to define several necessary operators in one fell swoop. Antc's comment seems to be suggesting that 0-adic relations be used as possrep components for type BOOLEAN. All right then, the user-defined scalar type definition would look like this:

TYPE BOOLEAN POSSREP {DEEDUM RELATION{}};

No, there's no need to define a distinct type to represent BOOLEAN. You could use "BOOLEAN" as a typename alias (that Tutorial D does not have, see other discussions) to denote values of type RELATION constrained to degree zero.

And if BOOLEAN is not system-defined, users would be required under TTM to give such a definition.

But TTM also requires support for truth-valued equality comparisons, so "=" would have to be user-defined too.

You're repeating the point from an earlier message, and that I rather think I answered comprehensively. If everything is a relation (and the the possrep for scalar values is a relation of cardinality one degree one), then you already have scalar equality comparison: it's spelled JOIN (result projected on to degree zero).

And it has to be available for value-pairs of every type. I'm prepared to be convinced that a generic signature might be possible, but what about the implementation. How can I write a RETURN statement that returns BOOLEAN(TABLE_DEE) if the operands are the selfsame value, otherwise BOOLEAN(TABLE_DUM)?

I note in passing that TRUE and FALSE could be user-defined operators: OPERATOR TRUE ( ) RETURNS BOOLEAN; RETURN BOOLEAN(TABLE_DEE); END OPERATOR, and likewise FALSE(), and the language might permit parens to be omitted in niladic operator invocations.

TRUE, FALSE could be aliases for values DEE, DUM. Not operators, not variables: what some languages call "manifest constants".

#48 · June 23, 2019, 1:24 pm

Quote from Hugh on June 23, 2019, 1:24 pm

Quote from AntC on June 23, 2019, 12:59 am

Quote from Hugh on June 22, 2019, 4:20 pm

Quote from AntC on June 22, 2019, 6:23 am

Quote from Hugh on June 11, 2019, 2:57 pm

Quote from AntC on June 11, 2019, 2:05 pm

Quote from Hugh on June 11, 2019, 10:40 am

Our reason for mandating BOOLEAN was to correct what we retrospectively regarded as an omission by Codd, ...

Mandating BOOLEAN is indeed sensible in practice; but in theory ...

RM Pre 1 for BOOLEAN prescribes "D shall support all four monadic and 16 dyadic logical operators, directly or indirectly, for this type." Then we could mimic Boolean operators using DUM, DEE as the values and traditional relational operators for all the logic you might need.

TTM prescribes BOOLEAN types to describe the results of evaluating integrity constraints (RM Pre 23). Typical practice (in Tutorial D) is that the formula for an integrity constraint is of the form IS_EMPTY( ... ).

We'd want DEE to correspond to TRUE, so the equivalent of IS_EMPTY( ... ) in constraints would be DEE NOT MATCHING ( ... ).

It's not very clear (IIRC from Chris's analysis of Codd's early papers) whether Codd omitted degree zero relations; or whether he anticipated them but suppressed that thought because it would cause conniptions amongst IBM engineers and top brass(?)

But DEE and DUM (which Codd also omitted and in fact deprecated, asking, "What are they for?") aren't truth values.

There's that slippery verb ' to be' again. I think you're failing to distinguish abstrep (a logical/abstract truth value) vs possrep (its representation in some D).

I think I can reasonably claim to understand that distinction quite well. A possrep is a syntactical device to define several necessary operators in one fell swoop. Antc's comment seems to be suggesting that 0-adic relations be used as possrep components for type BOOLEAN. All right then, the user-defined scalar type definition would look like this:

TYPE BOOLEAN POSSREP {DEEDUM RELATION{}};

No, there's no need to define a distinct type to represent BOOLEAN. You could use "BOOLEAN" as a typename alias (that Tutorial D does not have, see other discussions) to denote values of type RELATION constrained to degree zero.

And if BOOLEAN is not system-defined, users would be required under TTM to give such a definition.

But TTM also requires support for truth-valued equality comparisons, so "=" would have to be user-defined too.

You're repeating the point from an earlier message, and that I rather think I answered comprehensively. If everything is a relation (and the the possrep for scalar values is a relation of cardinality one degree one), then you already have scalar equality comparison: it's spelled JOIN (result projected on to degree zero).

And it has to be available for value-pairs of every type. I'm prepared to be convinced that a generic signature might be possible, but what about the implementation. How can I write a RETURN statement that returns BOOLEAN(TABLE_DEE) if the operands are the selfsame value, otherwise BOOLEAN(TABLE_DUM)?

I note in passing that TRUE and FALSE could be user-defined operators: OPERATOR TRUE ( ) RETURNS BOOLEAN; RETURN BOOLEAN(TABLE_DEE); END OPERATOR, and likewise FALSE(), and the language might permit parens to be omitted in niladic operator invocations.

TRUE, FALSE could be aliases for values DEE, DUM. Not operators, not variables: what some languages call "manifest constants".

But you appear now to be treating DEE and DUM as replacements for TRUE and FALSE, so what was all that about possreps for? As for your "explanation" about "=", please show me how to write an expression to replace "1 = 2" using JOIN. You could perhaps using DUM to represent zero, then REL{I REL{}}{I REL{}} to represent 1, and so on for the remaining natural numbers, but what about comparison of values of other types?

Hugh

Hugh

Quote from AntC on June 23, 2019, 12:59 am

Quote from Hugh on June 22, 2019, 4:20 pm

Quote from AntC on June 22, 2019, 6:23 am

Quote from Hugh on June 11, 2019, 2:57 pm

Quote from AntC on June 11, 2019, 2:05 pm

Quote from Hugh on June 11, 2019, 10:40 am

Our reason for mandating BOOLEAN was to correct what we retrospectively regarded as an omission by Codd, ...

Mandating BOOLEAN is indeed sensible in practice; but in theory ...

RM Pre 1 for BOOLEAN prescribes "D shall support all four monadic and 16 dyadic logical operators, directly or indirectly, for this type." Then we could mimic Boolean operators using DUM, DEE as the values and traditional relational operators for all the logic you might need.

TTM prescribes BOOLEAN types to describe the results of evaluating integrity constraints (RM Pre 23). Typical practice (in Tutorial D) is that the formula for an integrity constraint is of the form IS_EMPTY( ... ).

We'd want DEE to correspond to TRUE, so the equivalent of IS_EMPTY( ... ) in constraints would be DEE NOT MATCHING ( ... ).

It's not very clear (IIRC from Chris's analysis of Codd's early papers) whether Codd omitted degree zero relations; or whether he anticipated them but suppressed that thought because it would cause conniptions amongst IBM engineers and top brass(?)

But DEE and DUM (which Codd also omitted and in fact deprecated, asking, "What are they for?") aren't truth values.

There's that slippery verb ' to be' again. I think you're failing to distinguish abstrep (a logical/abstract truth value) vs possrep (its representation in some D).

I think I can reasonably claim to understand that distinction quite well. A possrep is a syntactical device to define several necessary operators in one fell swoop. Antc's comment seems to be suggesting that 0-adic relations be used as possrep components for type BOOLEAN. All right then, the user-defined scalar type definition would look like this:

TYPE BOOLEAN POSSREP {DEEDUM RELATION{}};

No, there's no need to define a distinct type to represent BOOLEAN. You could use "BOOLEAN" as a typename alias (that Tutorial D does not have, see other discussions) to denote values of type RELATION constrained to degree zero.

And if BOOLEAN is not system-defined, users would be required under TTM to give such a definition.

But TTM also requires support for truth-valued equality comparisons, so "=" would have to be user-defined too.

You're repeating the point from an earlier message, and that I rather think I answered comprehensively. If everything is a relation (and the the possrep for scalar values is a relation of cardinality one degree one), then you already have scalar equality comparison: it's spelled JOIN (result projected on to degree zero).

And it has to be available for value-pairs of every type. I'm prepared to be convinced that a generic signature might be possible, but what about the implementation. How can I write a RETURN statement that returns BOOLEAN(TABLE_DEE) if the operands are the selfsame value, otherwise BOOLEAN(TABLE_DUM)?

I note in passing that TRUE and FALSE could be user-defined operators: OPERATOR TRUE ( ) RETURNS BOOLEAN; RETURN BOOLEAN(TABLE_DEE); END OPERATOR, and likewise FALSE(), and the language might permit parens to be omitted in niladic operator invocations.

TRUE, FALSE could be aliases for values DEE, DUM. Not operators, not variables: what some languages call "manifest constants".

But you appear now to be treating DEE and DUM as replacements for TRUE and FALSE, so what was all that about possreps for? As for your "explanation" about "=", please show me how to write an expression to replace "1 = 2" using JOIN. You could perhaps using DUM to represent zero, then REL{I REL{}}{I REL{}} to represent 1, and so on for the remaining natural numbers, but what about comparison of values of other types?

Hugh

Coauthor of The Third Manifesto and related books.

#49 · June 23, 2019, 1:46 pm

Apparently AntC's algebraist is quite happy with such type puns. After all, the von Neumann natural numbers conflate 0 with {}, so the algebraists evidently are happy with nondistinct representations for distinct types, just at the machine level a static programming can represent both integers and floats as 64-bit values, even though zero is the only one with the same representation in both cases.

#50 · June 23, 2019, 1:48 pm

To correct my obvious error above (post in haste, repent at leisure): of course integers cannot be represented by relations with identical tuples in them, because there are no such relations. A para-Von-Neumann scheme like the one Hugh sketched out will work, though at the expense of type punning.

The Forum for Discussion about The Third Manifesto and Related Matters

First and second class citizens in TTM