Allow reserved identifiers as Attribute names?
Can I touch ground with the brains trust here. This is also by way of a bit of seasonal light-heartedness.
I believe that in Tutorial D syntax, attribute names can only appear within { ... } syntactic contexts:
- <relation exp>
{[ ALL BUT ] <attribute ref commalist>}-- or <tuple exp> - RELATION [ <heading> ]
{<tuple exp commalist>} - <tuple component> ::= <attribute name> <exp>
- <heading> ::=
{<attribute commalist>}
<attribute name> must be a bare name literal, not an expression.
The Haskell language also uses { ... } for field-name access; and the field name must be a bare name literal. It also supports dot-infix field access:
- <tuple exp>
.<attribute name> -- syntax sugar for <tuple exp>{<attribute name>} - The
.must be 'tightfix' (no intervening spaces) against the attribute bare name literal.
But unlike Tutorial D, Haskell is a programming language not a DBMS. Haskell programs access databases created by some other tool, with naming conventions outside Haskell's control. And in particular that might allow field names that happen to be Haskell reserved words. (type seems to be a particularly common name, for some reason.)
So there's a language proposal to (in effect) allow any name whatsoever in those syntactic positions, including and especially reserved words.
- Would that also work in Tutorial D?
- If it did, would you entertain it?
Could your eye parse:
S{ S#, CITY, WHERE }P{ P#, COLOUR, TYPE }
(Some dialects of) SQL kinda support arbitrary column names if you surround them with quotes 'COLUMN TYPE' including embedded spaces, or sometimes (TABLE WHERE) parens, square brackets, depending on dialect. So I suppose this is a realistic requirement.
Speaking for myself, I'd want to see stronger syntactic warning this reserved word is not appearing as a reserved word -- perhaps surround with "type" string quotes, which currently can't appear in such contexts.
The problem is familiar. The DB designer wants to choose names with business meaning, and that might mean attribute (and other) names not acceptable to the programming language. Of course.
Your 'language proposal' only meets this halfway. A creative designer will easily come up with names that are unparsable in any reasonable computer language. Such as `!@#$%^&*()`.
The usual solution is just to allow an alias. The field is S# in the database but is aliased to S_ or sx or S_hash in the language. I was surprised that TD did not allow this from the off.
The general solution to allowing users to choose any names they want is for the language to support those names being quoted, then they have all the flexibility of a character string literal. The quotes are then optional when the names can be parsed without ambiguity in that case. As far as I know, every dialect of SQL supports this already; different quoting characters are used for identifiers versus regular character string literals, which disambiguates which of these one has.
Both solutions work. The quoting solution is simple (simplistic?) but provides no insulation from DB language designer choices and IMHO verges on kludge. The alias solution introduces a layer of indirection, which may well prove useful for other purposes, and seems more elegant.
And never forget: "All problems in computer science can be solved by another level of indirection".
Quote from AntC on December 21, 2024, 2:58 am...
But unlike Tutorial D, Haskell is a programming language not a DBMS. Haskell programs access databases created by some other tool, with naming conventions outside Haskell's control. And in particular that might allow field names that happen to be Haskell reserved words. (
typeseems to be a particularly common name, for some reason.)So there's a language proposal to (in effect) allow any name whatsoever in those syntactic positions, including and especially reserved words.
- Would that also work in Tutorial D?
- If it did, would you entertain it?
Could your eye parse:
S{ S#, CITY, WHERE }P{ P#, COLOUR, TYPE }(Some dialects of) SQL kinda support arbitrary column names if you surround them with quotes
'COLUMN TYPE'including embedded spaces, or sometimes(TABLE WHERE)parens, square brackets, depending on dialect. So I suppose this is a realistic requirement.Speaking for myself, I'd want to see stronger syntactic warning this reserved word is not appearing as a reserved word -- perhaps surround with
"type"string quotes, which currently can't appear in such contexts.
Overloading reserved words to be used as variable/attribute/whatever names is fraught with peril, unduly complicates the parser, and harms readability.
I'd prefer that when declaring external relvars (as they're called in Rel) either external attribute/table/whatever names be automatically and algorithmically converted to valid attribute names (that's what Rel does) and/or provide a means to manually convert them. E.g., P{ P#, COLOUR, "TYPE" AS TYPE_ATTR } or similar.
Quote from dandl on December 21, 2024, 5:29 amI was surprised that TD did not allow this from the off.
Given its intended purpose, why would it?
Quote from Dave Voorhis on December 21, 2024, 9:09 pmOverloading reserved words to be used as variable/attribute/whatever names is fraught with peril, unduly complicates the parser, and harms readability.
Yes, my sentiments exactly. A leading light in the Haskell community is wanting to extend this putative 'feature' to allow native (not just imported) data declarations to use arbitrary/reserved word field names. I can't tell if they're joking/pushing the original proposers to the limit so as to show it's unworkable.
I'd prefer that when declaring external relvars (as they're called in Rel) either external attribute/table/whatever names be automatically and algorithmically converted to valid attribute names (that's what Rel does) and/or provide a means to manually convert them. E.g.,
P{ P#, COLOUR, "TYPE" AS TYPE_ATTR }or similar.
Yeah, similar to dandl's alias/indirection suggestion. Haskell has lots of ways to shorthand-name language constructs/expressions, but the constructs must be valid code (because in effect the rhs of the declaration just gets substituted in at the use site).
Quote from Dave Voorhis on December 21, 2024, 9:10 pmQuote from dandl on December 21, 2024, 5:29 amI was surprised that TD did not allow this from the off.
Given its intended purpose, why would it?
Because a DBMS is a tool for business. And it would help those liaising between the tool and the business to be able to use the same vocabulary. Something like SQL or COBOL is so prolix with reserved words, it's inevitable to get clashes. Of course you could put the business term as comment against the attribute name in source code, but that won't show up in user-facing developer tools for interactive queries -- say as a column heading in a display or a drop-down.
Quote from AntC on December 21, 2024, 11:03 pmQuote from Dave Voorhis on December 21, 2024, 9:10 pmQuote from dandl on December 21, 2024, 5:29 amI was surprised that TD did not allow this from the off.
Given its intended purpose, why would it?
Because a DBMS is a tool for business. And it would help those liaising between the tool and the business to be able to use the same vocabulary. Something like SQL or COBOL is so prolix with reserved words, it's inevitable to get clashes. Of course you could put the business term as comment against the attribute name in source code, but that won't show up in user-facing developer tools for interactive queries -- say as a column heading in a display or a drop-down.
I see the value in an Industrial D, but not in a Tutorial D.
Quote from dandl on December 21, 2024, 12:44 pmThe quoting solution is simple (simplistic?) but provides no insulation from DB language designer choices and IMHO verges on kludge.
How is quoting a kludge? If anything, it is the most elegant possible solution. Assuming that only user-defined entities can be quoted and all built-ins like keywords or reserved words can never be quoted.