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".