Operators on tuples/'Expressively complete'/RM Pre 6
Erwin, there's no need for such language.
Attribute and relvar names can be rendered as strings in the same way as any program source starts life as a string. You can glue attribute names together with other strings (perhaps via a macro) to produce a whole program source; then compile that source. That doesn't meet OO Pre 1, as I understand it.
There's plenty of applications supporting SQL ad-hoc querying that do exactly that. They're not smart enough to detect if the user has concocted a valid query; they merely hand the string across to the SQL interpreter; it might not even be valid syntax, let alone type-safe.
(Note the catalog might change between runs, such that what was type-safe before is now not. Then the only way to get applications in lock-step typing with the data is to compile them into the catalog as well -- aka 'stored procedures'.)
Yes. To add to that, attribute names never appear in isolation, they only appear in the language as part of a type name. Attribute names are exactly like field or tag or struct member or internal variable names in this respect: they disappear after compilation unless they are explicitly preserved. Yes, it is useful to have attribute and relvar names in the user-visible catalog, but it's not automatic or required.
Although not stated, it seems the catalog needs to store relation types, scalar types (but perhaps not tuple types), constraints and operators as well. What form they take is left to the implementor.
Quote from Erwin on October 2, 2022, 12:56 pm
The effects you'd be getting if users start querying the catalog to find, e.g. all the relvars that have an attribute named 'RELVARNAME' (the query might be something like 'RELVARATTRIBUTE WHERE ATTRIBUTENAME = "RELVARNAME" {RELVARNAME}' are as follows :
I'm afraid your using different styles of quotes isn't helping. Perhaps you could at least use the editor's Format-> <>Code to show which is code? Tutorial D then uses single quotes 'PNO' to denote a (what it calls) CHAR literal. (I'm more familiar with using single quotes to denote a single-Char literal vs double quotes to denote a multi-char (possibly zero) aka String literal. Following Tutorial D will at least put us all at the same disadvantage.)
Perhaps we could also adopt some convention to the effect variables are spelled lower-case (or at least non-variables start Upper-case)?
I'm afraid your two uses of RELVARNAME in that query don't mean anything to me. Why the double-quotes? Is the suffixed-in-curly-braces doing Tutorial D's projection? I think I mentioned I'd prefer Tutorial D had an explicit operator for projection. If it is projection, please show parens ( ... ) so I can see what the projection scopes over.
- if type CHAR is used for the name-attributes and the user queries with an invalid name then the only result he'd be getting back, is the answer "no such relvars found"
- but if a NAME type is used for the name-attributes and the user queries with an invalid name then his WHERE clause would have to be something like WHERE ATTRIBUTENAME = NAME("RELVARNAME") and if "RELVARNAME" were an invalid name then this would give rise to the value selector invocation raising an error perhaps saying "invalid name RELVARNAME specified".
Which of the two do you think is the best option ?
Am I allowed a value selector NAME(SST(stringyvar, 2, 10)) or NAME( CONCAT(stringyvar1, stringyvar2) )? Is my query allowed to search for wildcard matches like all attribute names containing '%NAME%'? I think there'd be a lot of pragmatic reasons that names in the catalog could be (convertible to) String.
Note: SQL '%NAME%' for a wildcard search is at first look a CHAR; but it has syntax inside it that gets interpreted at run time, because it's an argument of LIKE rather than =. SQL is exhibiting the sort of syntactic schizophrenia that good language design ( RM Pre 26) is prescribing against.
Quote from AntC on October 3, 2022, 6:36 am
Note: SQL
'%NAME%'for a wildcard search is at first look aCHAR; but it has syntax inside it that gets interpreted at run time, because it's an argument ofLIKErather than=. SQL is exhibiting the sort of syntactic schizophrenia that good language design ( RM Pre 26) is prescribing against.
Heh heh I was doing a data conversion of a Name&Address database that clumped names together as one big string to a more modern system that wanted separate fields for title, Initials Esq, Jnr, etc. Mr A B & Mrs C D Smith -> Mr & Mrs | A B & C D | Smith. We wanted to make this parameter-driven, because the company was a conglomerate whose child/acquired companies had used different conventions/formatting for what turned out to be the same customer.
I discovered you could put wildcard patterns in a database field; then run a query with ... FROM ADDRESSES, DECODER WHERE ADDRESSES.OLDNAME LIKE DECODER.PATTERN. This was an Oracle extension, SQL-server didn't support it.
Supplier numbers and part numbers "can be rendered as strings" too. So can integers and dates and complex numbers and trigonometric angles and what have you. So why bother with a type system at all ?
Easy one. First off, just about every data item intended for viewing or printing is going to be converted into text form, usually Unicode these days. Ditto data meant to be sent through an exchange medium such as email, Internet, etc. If it wasn't text you wouldn't be able to read it.
But the point of a type system is to make programs safer.
Cardelli: The fundamental purpose of a type system is to prevent the occurrence of execution errors during the running of a program. http://lucacardelli.name/Papers/TypeSystems.pdf
So the type system in the catalog is intended avoid certain types of errors during the execution of queries.
But I think you knew that.
Then
TupleRenameis built from<tuple> TupleProject TUPLE{ <attrName> <don'tcarevalue> }to getTHE_<attrName>value at the as-was attribute;TupleRemoveto snip off that attribute (again with a `don'tcarevalue' in a singleton Tuple literal);TupleExtendto glue on the to-be attribute (as a singleton Tuple literal).
The <don'tcarevalue> is perhaps the only questionmark here. TupleProject would never care about the value on the right hand side, so for ergonomic reasons I would like to have a <don'tcarevalue> in my toolbox.
Otherwise I think this would be complete as far as I can tell.
Quote from AntC on October 3, 2022, 6:36 amQuote from Erwin on October 2, 2022, 12:56 pmThe effects you'd be getting if users start querying the catalog to find, e.g. all the relvars that have an attribute named 'RELVARNAME' (the query might be something like 'RELVARATTRIBUTE WHERE ATTRIBUTENAME = "RELVARNAME" {RELVARNAME}' are as follows :
I'm afraid your using different styles of quotes isn't helping. Perhaps you could at least use the editor's
Format-> <>Codeto show which is code? Tutorial D then uses single quotes'PNO'to denote a (what it calls)CHARliteral. (I'm more familiar with using single quotes to denote a single-Char literal vs double quotes to denote a multi-char (possibly zero) akaStringliteral. Following Tutorial D will at least put us all at the same disadvantage.)Perhaps we could also adopt some convention to the effect variables are spelled lower-case (or at least non-variables start Upper-case)?
I'm afraid your two uses of
RELVARNAMEin that query don't mean anything to me. Why the double-quotes? Is the suffixed-in-curly-braces doing Tutorial D's projection? I think I mentioned I'd prefer Tutorial D had an explicit operator for projection. If it is projection, please show parens( ... )so I can see what the projection scopes over.Am I allowed a value selector
NAME(SST(stringyvar, 2, 10))orNAME( CONCAT(stringyvar1, stringyvar2) )? Is my query allowed to search for wildcard matches like all attribute names containing'%NAME%'? I think there'd be a lot of pragmatic reasons that names in the catalog could be (convertible to)String.Note: SQL
'%NAME%'for a wildcard search is at first look aCHAR; but it has syntax inside it that gets interpreted at run time, because it's an argument ofLIKErather than=. SQL is exhibiting the sort of syntactic schizophrenia that good language design ( RM Pre 26) is prescribing against.
SIRA_PRISE version of the query :
PROJECT ( RESTRICT ( RELVARATTRIBUTE , EQ ( ATTRIBUTENAME , NAME(RELVARNAME) ) ) , (RELVARNAME) )
PROJECT & RESTRICT : invocation names of the relational operators (operator generators, in fact, but let's stick with the territory) of that name
RELVARATTRIBUTE : reference to the database relvar whose name is the NAME value NAME(RELVARATTRIBUTE)
EQ : invocation name of the equality operator generator
ATTRIBUTENAME : reference to the attribute within the RELVARATTRIBUTE relvar whose [attribute] name is the NAME value NAME(ATTRIBUTENAME)
NAME(RELVARNAME) : selector of the NAME value that we want to query for / filter on / ... More verbosely, NAME(STRING(RELVARNAME)) but that is often not needed, depending on the set of possreps
(RELVARNAME) : projection spec, telling the system we're interested in the NAME values that appear in the result tuples for the attribute whose name is the NAME value NAME(RELVARNAME).
In a more Tutorial D-like style but using the CARTESIAN/POLAR style for the value selector instead of quotes :
RELVARATTRIBUTE WHERE ATTRIBUTENAME = NAME(RELVARNAME) { RELVARNAME}
where relvar RELVARATTRIBUTE has attributes RELVARNAME and ATTRIBUTENAME
And the point was that the NAME(RELVARNAME) part can take on the responsibility for raising the appropriate error signal if and when an invalid name is used instead (but not if everything is just typed plain string). Born coders who will die a coder will say, "but I can do that in my code too". And then I say that all that coding is part of the problem space, not of the solution space.
"Why the double-quotes?" Because I thought quoting would be more familiar as a way for denoting STRING/CHAR values, rather than the more lisp-ish NAME(...) or STRING(...)
And getting criticized in the space of no more than three lines both for not following Tutorial D syntax (the quoting, apparently) AS WELL AS for effectively following it (the projection) is, eurhm, notable.
"I think there'd be a lot of pragmatic reasons that names in the catalog could be (convertible to) String." I don't "think" that, I KNOW that (and I DO that). None of that implies that we should forego the benefits of being able to recognize invalid constructs as the invalid constructs that they are on account of not representing a valid value of some type. What those benefits are ? We can get earlier error detection without one extra word of code having to be written for getting it. The born-and-died-a-coder's approach won't ever give you that.
And yes, I have a MATCHES operator which is little more than a wrapper for java regex matching, which I defined in a STRING version with signature MATCHES ( STRING , STRING ) but also in a NAME version with signature MATCHES ( NAME , STRING ) and which is just shorthand for MATCHES ( THE_STRING ( name_arg ) , pattern_arg ).
Quote from Erwin on October 3, 2022, 5:12 pmSIRA_PRISE version of the query :
PROJECT ( RESTRICT ( RELVARATTRIBUTE , EQ ( ATTRIBUTENAME , NAME(RELVARNAME) ) ) , (RELVARNAME) )
Incidentally, looking at that entire expression, one could observe that there is almost not a single word in there that is not a name. ALMOST NOT A SINGLE WORD. Operator name, operator name, relvar name, operator name, attribute name, type name, something that has to be a name or everything will fail entirely (though admittedly that is only the case because the type name at hand happened to be NAME(NAME) ), attribute name. So why would it be interesting to have a NAME type ?
Quote from dandl on October 3, 2022, 12:36 pmBut I think you knew that.
Yeah. Let me try one that I think you "know" too, even if you might realise that only if it is pointed out to you :
A picture of a relation is not the same thing as the relation itself.
Which by the same token, could arguably lead to :
A picture of a value is not the same thing as the value itself.
And a textual rendering of a value is, very much indeed, just a "picture of a value".