Quote from Erwin on March 20, 2020, 8:41 am

Quote from dandl on March 19, 2020, 11:50 pm

(To dispense with issues of physical encoding of the CHAR itself, define a CHAR as a variable-length array of UCS code point numbers.  The INT value selector function is the function that maps e.g. the array [49, 48] to the integer value 10.  And that (partial) function has CHAR as its domain, so in computer terms the argument is of type CHAR.)

This is a misunderstanding/misrepresentation of what a compiler does. The token 10 is recognised in the text of the program by reference to some kind of specification and assigned to a token type very early in the process. In a language like C the tokens 10, 0x0a and 012 are all tokens of type integer with the value of 10, but the token "10" is of type string. The function as defined by the specification for the compiler in the case of SomeSelector(10) has a domain of integer, while SomeSelector("10") has a domain of character. They should not be confused.

FWIW a compiler will only ever define a handful of token types (eg 10, 10.0, 10e0, 10d, "10", '10', @"10", $'10', X10, etc) even if it has countless types in its type system.

You have just confirmed that my pov is right.  Your "tokens" as you call them, are substrings of the program text.  I repeat, subSTRINGs.  The number 10 never appears in program text.   The token string "10" does.  That the "conversion" to the number 10 "happens very early in the process" is entirely irrelevant.  It happens.  Case rested.

Quote from AntC on March 20, 2020, 9:35 am

Quote from Erwin on March 20, 2020, 8:41 am

Quote from dandl on March 19, 2020, 11:50 pm

(To dispense with issues of physical encoding of the CHAR itself, define a CHAR as a variable-length array of UCS code point numbers.  The INT value selector function is the function that maps e.g. the array [49, 48] to the integer value 10.  And that (partial) function has CHAR as its domain, so in computer terms the argument is of type CHAR.)

This is a misunderstanding/misrepresentation of what a compiler does. The token 10 is recognised in the text of the program by reference to some kind of specification and assigned to a token type very early in the process. In a language like C the tokens 10, 0x0a and 012 are all tokens of type integer with the value of 10, but the token "10" is of type string. The function as defined by the specification for the compiler in the case of SomeSelector(10) has a domain of integer, while SomeSelector("10") has a domain of character. They should not be confused.

FWIW a compiler will only ever define a handful of token types (eg 10, 10.0, 10e0, 10d, "10", '10', @"10", $'10', X10, etc) even if it has countless types in its type system.

You have just confirmed that my pov is right.  Your "tokens" as you call them, are substrings of the program text.  I repeat, subSTRINGs.  The number 10 never appears in program text.   The token string "10" does.  That the "conversion" to the number 10 "happens very early in the process" is entirely irrelevant.  It happens.  Case rested.

Erwin sorry, I don't get what is your "pov"; but so far I haven't seen anything from you that seems remotely right.

Please explain your claim using some well-established terminology (not your own, which seems to be home-grown) from some well-established authority. Perhaps you could use RM Pre 4. (But I'd prefer you to use Strachey 1967.)

It would help me if you'd use an example not of INT but of BOOL, because the tokens denoting those values (TRUE, FALSE) are just names, lexically indistinguishable from var names or type names. It's easy to arrange an assignment to a Boolean var with or without the appearance of any BOOL literal:

var BOOL myBool;
var BOOL myBool2;
myBool := TRUE;
myBool2 := 7 > 5;
... TUP{ y myBool, z myBool2 } ...;

Same questions: what are the Selectors? what is/are their argument(s)? Whatever you're claiming should apply equally to literals denoting some value within the semantics of the language or expressions evaluating to that same value -- that's what we call 'referential transparency', and is a Good Thing.

Program text is text. It's not of any type in the semantics of the language until it's parsed and compiled. It's hugely misleading to claim "10" appearing in program text is CHAR or is a parameter. The text format/encoding/type is actually defined by the file system in which the source file is stored. When your earlier message says "define a CHAR as a variable-length array of UCS code point numbers" that's just wrong. That's (possibly) a definition of the PhysRep of text in the file system. OTOH CHAR is a system-defined type in Tutorial D; and the definition (if there is one) is in terms of PossReps not the 'storage structure definition language', on which TTM is deliberately and correctly silent. Addit: the only PossRep for CHAR in Tutorial D has single quotes around the string content, which there aren't in "10".

Quote from Hugh on March 20, 2020, 12:41 pm

Quote from AntC on March 19, 2020, 9:10 pm

Quote from Hugh on March 19, 2020, 12:39 pm

Quote from AntC on March 19, 2020, 12:10 am

Hugh, I put it to you that you never write bare TUP{ x 1 } in even the most ad hoc of ad hoc queries.

How dare you make such an accusation!  Here's the very first saved Rel script that I looked at, knowing that in fact I make extensive use of tuple literals.

/* PCNoRec% of cases with at least one operand = Digit have no recalcitrants */
rel{
tup{Digit 1, PCNoRecs Percent(Count((Studied join CasesWith1) not matching Recalcitrant), count(Studied join CasesWith1))},
...
}
order(asc PCNoRecs)

Please let me know if you want to any more.  No, on second thoughts, don't.

I agree that code is in no way easy on the eye. Presumably it's within a finger-slip to get

tup{Digit 1, PCNoRecs Percent(Count((Studied join CasesWith2) not matching Recalcitrant), count(Studied join CasesWith3))}

I'd count this amongst my earlier comments "I do want to make the coding sufficiently verbose for the programmer to stop and ask themselves whether they might be doing something daft." You are doing something daft.

• I think my "accusation" stands: that expression is not a query but data entry.
• I said "If you're writing TUP{ x 1 } , it's to JOIN/etc with a database attribute or query result from the database"; and that is indeed what's going on: Digit 1 is joining to the 1 in CasesWith1, which presumably deeply buried within its content has a Digit 1 (or perhaps a CHAR with a 1 amongst others).
• I'm interested what limits to expressivity in Rel you're bumping into such that you're encoding data content into the name of a relvar. Does that tell us there's something wrong with the RM, or merely wrong with your schema design?
• Can you for example in Rel get the relvar name from the catalogue (or all of the form CasesWithn), cast it to CHAR, extract the last character, cast that to INT? Can you at the same time put that relvar name into a query expression to obtain your Percent and Count statistics? You'll have seen complaints on the forum that TTM 's relvar names (and attribute names) are not first-class in that you can't pass them as arguments to functions. You seem to have found the perfect illustration of the need -- that is, if there's not something wrong with your schema.

 

Lastly (and I nearly included this in my 'specification'), if the x 1 is not Joining/etc to any other attribute x or RENAMEd to x coming from the database, etc; then it doesn't matter what DOMAIN for the 1 then it might as well default to Integer. (This also is behaviour already supported in Haskell.)

'I think my "accusation" stands: that expression is not a query but data entry.'

What on earth led you to that conclusion?  It is just a relation expression.  When evaluated it does answer a question.  It does not update the database, nor is it ever used in an update expression.

I don't understand your last paragraph.  If an attribute is named X, then surely its domain is X.  If I want an attribute whose values are integers, don't I have to call it INTEGER or some synonym thereof defined by ROLE?  And, btw, if I use attribute renaming to call it S#, S# being a name for a domain that isn't the domain of X, does this S# now have domain X instead of S#?  (I thought it would just be an error.)

Hugh

Quote from Hugh on March 20, 2020, 12:54 pm

Quote from AntC on March 20, 2020, 12:15 am

Quote from AntC on March 19, 2020, 9:10 pm

Quote from Hugh on March 19, 2020, 12:39 pm

Quote from AntC on March 19, 2020, 12:10 am

Hugh, I put it to you that you never write bare TUP{ x 1 } in even the most ad hoc of ad hoc queries.

How dare you make such an accusation!  Here's the very first saved Rel script that I looked at, knowing that in fact I make extensive use of tuple literals.

/* PCNoRec% of cases with at least one operand = Digit have no recalcitrants */
rel{
tup{Digit 1, PCNoRecs Percent(Count((Studied join CasesWith1) not matching Recalcitrant), count(Studied join CasesWith1))},
...
}
order(asc PCNoRecs)

Please let me know if you want to any more.  No, on second thoughts, don't.

I agree that code is in no way easy on the eye. Presumably it's within a finger-slip to get

tup{Digit 1, PCNoRecs Percent(Count((Studied join CasesWith2) not matching Recalcitrant), count(Studied join CasesWith3))}

I'd count this amongst my earlier comments "I do want to make the coding sufficiently verbose for the programmer to stop and ask themselves whether they might be doing something daft." You are doing something daft.

 

Am I being too cruel in critiquing Hugh's schema and opining there's something daft? TTM-ers do this all the time with others' schemas: typically somebody has gone deep down a rabbit hole with a schema relying on Nullable columns, and then asks how to express a query that seems impossible. We had on the forum recently an example 'Company Cars' of a schema where the designers head was full of Nulls and SQL's inability to express Exclusion Dependencies. It sometimes takes a lot of careful explaining to back the designer out of the rabbit hole.

So I can only guess how Hugh got down this rabbit hole. Why on earth are there nine separate relvars with (presumably) the same schema, differing only in the relvar name? Why on earth is there any expression at all with nine near-identical lines of code differing only in which relvar name they're accessing? Clearly Digit is reference data in this application (dare I say a DOMAIN) and the nine Digits should be in a reference relvar (yes even though we all know what the nine digits are). Clearly whatever these CasesWithn relvars are, their content should be in one relvar with an extra attribute Digit. Clearly that 9-line expression should be written as one line with the Digit drawn from the Digit reference relvar, and Joined to the CasesWithn relvar.

I'll speculate (remembering from when Hugh earlier described his 'four fours' experiment) there's a relvar holding formulas as CHAR. A formula might include many appearances of some digit(s). Then CasesWithn should be a Virtual:

CasesWithn := (Digits TIMES Cases) WHERE Cast_to_CHAR( Digit ) isSubStringOf( Formula );

And Hugh's ugly nine lines should be a straightforward SUMMARIZE CasesWithn ... GROUP BY Digit ....

I'll speculate further that Hugh originally designed a schema purely for the 'four fours' cases, where there was no need for a Digits reference relvar, because it would only have contained a four. So when he expanded the exercise to other digits, he merely cloned the Cases schema to CasesWith3, CasesWith2, etc.

Sorry, but I find your arrogant speculations unbearable.  My expression serves its purpose and that's all there is to it.  Here is its result, using order(asc PCNoRecs):

Digit INTEGER	PCNoRecs RATIONAL
6	78.79
7	80.0
2	82.42
1	84.85
3	85.45
8	86.06
5	92.73
4	96.97
9	96.97

Now put your money where your mouth is and show me how you would code it up.

Hugh

Quote from dandl on March 20, 2020, 1:16 pm

... the remark was concerned only with system-defined scalar types (such as INT).  And for such types, yes the value selector does take a CHAR argument.  If there were no argument then it would be impossible to select more than one distinct value of the type. ...

In the expression TUP{ x 3 }, in which 3 is INT: where is the value selector? where is its argument?

As I said earlier, wherever you write code to construct a value the compiler must supply an invocation of a selector. The compiler must first determine the type of attribute x, then supply a selector that takes integer 3 as an argument and returns a value of the required type. If the intention is that x should be of type (say) product then you need to find a place to say that in  your code fragment.

I was arguing against treating tokens as all of type CHAR inherited from the text in which they're presumably written. You are raising a different point.

And in this Tutorial D code:

var INT threeInt;
threeInt := 3;
... TUP{ x threeInt } ... ;

does the threeInt appearing in the TUP{ } have the same lexical status as the 3 appearing inside TUP{ }? Then is there a CHAR argument appearing somewhere?

The threeInt is a declared variable, so it has the declared type. Appearing inside TUP{} it has a token type of symbol, and has to be looked up in the symbol table to find out what its declared type might be.

My understanding (prior to Erwin dipping his oar in) was that 3 is a Selector taking no arguments. 4 is a different Selector. That's how to "select more than one distinct value of the type".

I guess you could build a compiler that way, but it's not usual AFAIK. It still doesn't change that initialisation of x and threeInt requires a selector returning the correct type.

Quote from Dave Voorhis on March 20, 2020, 3:24 pm

Quote from dandl on March 20, 2020, 1:16 pm

I guess you could build a compiler that way, but it's not usual AFAIK.

When I taught compiler/interpreter construction, something I often pointed out was that although there are certain conventions for implementing lexxers, parsers, interpreters, optimisers and code generators -- and there is a body of academic and practical work around these -- there are no compiler police who will arrest you for deviating from common practice, and there are marvelous examples of interesting deviation like FORTH and LISP. In short, there are no rules, and there is a lot of variety in the conventions. So what's usual or not doesn't really matter, as long as the result meets performance and code quality requirements.

Quote from Dave Voorhis on March 20, 2020, 3:53 pm

Quote from AntC on March 20, 2020, 4:31 am

Quote from dandl on March 19, 2020, 11:50 pm

(To dispense with issues of physical encoding of the CHAR itself, define a CHAR as a variable-length array of UCS code point numbers.  The INT value selector function is the function that maps e.g. the array [49, 48] to the integer value 10.  And that (partial) function has CHAR as its domain, so in computer terms the argument is of type CHAR.)

This is a misunderstanding/misrepresentation of what a compiler does. The token 10 is recognised in the text of the program by reference to some kind of specification and assigned to a token type very early in the process. In a language like C the tokens 10, 0x0a and 012 are all tokens of type integer with the value of 10, but the token "10" is of type string. The function as defined by the specification for the compiler in the case of SomeSelector(10) has a domain of integer, while SomeSelector("10") has a domain of character. They should not be confused.

FWIW a compiler will only ever define a handful of token types (eg 10, 10.0, 10e0, 10d, "10", '10', @"10", $'10', X10, etc) even if it has countless types in its type system.

Thank you David, yes. I continue to not see what Erwin means about "zero possreps". If Dave now gets it, perhaps he could have a crack at explaining.

Re Erwin's first para that David elided:

... the remark was concerned only with system-defined scalar types (such as INT).  And for such types, yes the value selector does take a CHAR argument.  If there were no argument then it would be impossible to select more than one distinct value of the type. ...

In the expression TUP{ x 3 }, in which 3 is INT: where is the value selector? where is its argument? And in this Tutorial D code:

var INT threeInt;
threeInt := 3;
... TUP{ x threeInt } ... ;

does the threeInt appearing in the TUP{ } have the same lexical status as the 3 appearing inside TUP{ }? Then is there a CHAR argument appearing somewhere?

My understanding (prior to Erwin dipping his oar in) was that 3 is a Selector taking no arguments. 4 is a different Selector. That's how to "select more than one distinct value of the type".

What are the POSSREPs for INTEGER, CHARACTER, RATIONAL, and BOOLEAN?

What are the selectors for INTEGER, CHARACTER, RATIONAL, and BOOLEAN?

One answer is, "they're built-in... it's compiler magic" and that would be sufficient for most purposes.

Alternatively, we can assume that the lexical parsing phase will identify literals in the source code (which is a single string of characters) and represent them as strings of characters (i.e., substrings of the string of source code) along with their lexical type, such as integer, floating_point, string, identifier, true, false.

Then we assume the following selectors: INTEGER(CHARACTER), CHARACTER(CHARACTER), RATIONAL(CHARACTER), BOOLEAN(CHARACTER).

Each lexical type is mapped to a corresponding selector, so integer maps to INTEGER(CHARACTER), floating_point maps to RATIONAL(CHARACTER), string maps to CHARACTER(CHARACTER), and both true and false map to BOOLEAN(CHARACTER).

Each selector parses its CHARACTER parameter and returns an appropriate value of the given type.

There no visible POSSREPs, though -- that's compiler magic, or at least all hidden representation, and thus "zero possreps".

Though you can make THE_CHARACTER(...) available for each type, which returns the canonical string representation of that type and is used for display/output purposes.

At least, that's how I interpret it and internally, it's how Rel interprets it too.

Quote from Erwin on March 20, 2020, 5:52 pm

Quote from Dave Voorhis on March 20, 2020, 3:53 pm

Quote from AntC on March 20, 2020, 4:31 am

Quote from dandl on March 19, 2020, 11:50 pm

(To dispense with issues of physical encoding of the CHAR itself, define a CHAR as a variable-length array of UCS code point numbers.  The INT value selector function is the function that maps e.g. the array [49, 48] to the integer value 10.  And that (partial) function has CHAR as its domain, so in computer terms the argument is of type CHAR.)

This is a misunderstanding/misrepresentation of what a compiler does. The token 10 is recognised in the text of the program by reference to some kind of specification and assigned to a token type very early in the process. In a language like C the tokens 10, 0x0a and 012 are all tokens of type integer with the value of 10, but the token "10" is of type string. The function as defined by the specification for the compiler in the case of SomeSelector(10) has a domain of integer, while SomeSelector("10") has a domain of character. They should not be confused.

FWIW a compiler will only ever define a handful of token types (eg 10, 10.0, 10e0, 10d, "10", '10', @"10", $'10', X10, etc) even if it has countless types in its type system.

Thank you David, yes. I continue to not see what Erwin means about "zero possreps". If Dave now gets it, perhaps he could have a crack at explaining.

Re Erwin's first para that David elided:

... the remark was concerned only with system-defined scalar types (such as INT).  And for such types, yes the value selector does take a CHAR argument.  If there were no argument then it would be impossible to select more than one distinct value of the type. ...

In the expression TUP{ x 3 }, in which 3 is INT: where is the value selector? where is its argument? And in this Tutorial D code:

var INT threeInt;
threeInt := 3;
... TUP{ x threeInt } ... ;

does the threeInt appearing in the TUP{ } have the same lexical status as the 3 appearing inside TUP{ }? Then is there a CHAR argument appearing somewhere?

My understanding (prior to Erwin dipping his oar in) was that 3 is a Selector taking no arguments. 4 is a different Selector. That's how to "select more than one distinct value of the type".

What are the POSSREPs for INTEGER, CHARACTER, RATIONAL, and BOOLEAN?

What are the selectors for INTEGER, CHARACTER, RATIONAL, and BOOLEAN?

One answer is, "they're built-in... it's compiler magic" and that would be sufficient for most purposes.

Alternatively, we can assume that the lexical parsing phase will identify literals in the source code (which is a single string of characters) and represent them as strings of characters (i.e., substrings of the string of source code) along with their lexical type, such as integer, floating_point, string, identifier, true, false.

Then we assume the following selectors: INTEGER(CHARACTER), CHARACTER(CHARACTER), RATIONAL(CHARACTER), BOOLEAN(CHARACTER).

Each lexical type is mapped to a corresponding selector, so integer maps to INTEGER(CHARACTER), floating_point maps to RATIONAL(CHARACTER), string maps to CHARACTER(CHARACTER), and both true and false map to BOOLEAN(CHARACTER).

Each selector parses its CHARACTER parameter and returns an appropriate value of the given type.

There no visible POSSREPs, though -- that's compiler magic, or at least all hidden representation, and thus "zero possreps".

Though you can make THE_CHARACTER(...) available for each type, which returns the canonical string representation of that type and is used for display/output purposes.

At least, that's how I interpret it and internally, it's how Rel interprets it too.

Voilà.  No way I can do better.  And it saves people from uttering utter nonsense like "the integer selector takes the value 3 as an argument and returns the value 3".  (That sounds like an "identity selector" to me and it simply need not exist.)  But alas it seems people are so entrenched in the views imposed by current existing technology / most prevalent practices that they cannot even imagine things organized (or, well, at least conceptually seen) differently.

 

Quote from AntC on March 20, 2020, 9:28 pm

Quote from Erwin on March 20, 2020, 5:52 pm

Quote from Dave Voorhis on March 20, 2020, 3:53 pm

Quote from AntC on March 20, 2020, 4:31 am

Quote from dandl on March 19, 2020, 11:50 pm

(To dispense with issues of physical encoding of the CHAR itself, define a CHAR as a variable-length array of UCS code point numbers.  The INT value selector function is the function that maps e.g. the array [49, 48] to the integer value 10.  And that (partial) function has CHAR as its domain, so in computer terms the argument is of type CHAR.)

This is a misunderstanding/misrepresentation of what a compiler does. The token 10 is recognised in the text of the program by reference to some kind of specification and assigned to a token type very early in the process. In a language like C the tokens 10, 0x0a and 012 are all tokens of type integer with the value of 10, but the token "10" is of type string. The function as defined by the specification for the compiler in the case of SomeSelector(10) has a domain of integer, while SomeSelector("10") has a domain of character. They should not be confused.

FWIW a compiler will only ever define a handful of token types (eg 10, 10.0, 10e0, 10d, "10", '10', @"10", $'10', X10, etc) even if it has countless types in its type system.

Thank you David, yes. I continue to not see what Erwin means about "zero possreps". If Dave now gets it, perhaps he could have a crack at explaining.

Re Erwin's first para that David elided:

... the remark was concerned only with system-defined scalar types (such as INT).  And for such types, yes the value selector does take a CHAR argument.  If there were no argument then it would be impossible to select more than one distinct value of the type. ...

In the expression TUP{ x 3 }, in which 3 is INT: where is the value selector? where is its argument? And in this Tutorial D code:

var INT threeInt;
threeInt := 3;
... TUP{ x threeInt } ... ;

does the threeInt appearing in the TUP{ } have the same lexical status as the 3 appearing inside TUP{ }? Then is there a CHAR argument appearing somewhere?

My understanding (prior to Erwin dipping his oar in) was that 3 is a Selector taking no arguments. 4 is a different Selector. That's how to "select more than one distinct value of the type".

What are the POSSREPs for INTEGER, CHARACTER, RATIONAL, and BOOLEAN?

What are the selectors for INTEGER, CHARACTER, RATIONAL, and BOOLEAN?

One answer is, "they're built-in... it's compiler magic" and that would be sufficient for most purposes.

Alternatively, we can assume that the lexical parsing phase will identify literals in the source code (which is a single string of characters) and represent them as strings of characters (i.e., substrings of the string of source code) along with their lexical type, such as integer, floating_point, string, identifier, true, false.

Then we assume the following selectors: INTEGER(CHARACTER), CHARACTER(CHARACTER), RATIONAL(CHARACTER), BOOLEAN(CHARACTER).

Each lexical type is mapped to a corresponding selector, so integer maps to INTEGER(CHARACTER), floating_point maps to RATIONAL(CHARACTER), string maps to CHARACTER(CHARACTER), and both true and false map to BOOLEAN(CHARACTER).

Each selector parses its CHARACTER parameter and returns an appropriate value of the given type.

There no visible POSSREPs, though -- that's compiler magic, or at least all hidden representation, and thus "zero possreps".

Though you can make THE_CHARACTER(...) available for each type, which returns the canonical string representation of that type and is used for display/output purposes.

At least, that's how I interpret it and internally, it's how Rel interprets it too.

Ok thank you Dave that makes sense: 3 appearing in program text is a shorthand/magic for an invocation of a selector with argument. Then trying to return to the jumping-off point of DOMAIN/ROLE and how TUP{ S# 3 } works, I'm saying 3 is a shorthand/magic for an invocation of a polymorphic function with an argument.

Voilà.  No way I can do better.  And it saves people from uttering utter nonsense like "the integer selector takes the value 3 as an argument and returns the value 3".

Erwin please don't use quotes unless you are quoting. AFAICT nobody uttered that. If you're claiming I said that, I very carefully didn't propose anything called 'selector' because that's a TTM term and I'm objecting to TTM's layers of circumlocution.

  (That sounds like an "identity selector" to me and it simply need not exist.)  But alas it seems people are so entrenched in the views imposed by current existing technology / most prevalent practices that they cannot even imagine things organized (or, well, at least conceptually seen) differently.

 

Which "people"? Which "views"? "organized differently" to what? I don't see what Dave describes as being different to one of the prevalent practices. There are many practices, as he says. Whereas what you were trying to describe bore no relation to anything I could make sense of.