Allow reserved identifiers as Attribute names?
To be clear, I'm proposing that quoted is the default natural syntax for identifiers, and that writing identifiers non-quoted is just a common supported shorthand for when that shorthand isn't ambiguous. This also means that naive code generators can just generate the D code in quoted form all the time and not have to worry about special cases, and only when users hand-write the D code they can leave the quotes out for typical cases.
Quote from Darren Duncan on December 22, 2024, 5:34 amTo be clear, I'm proposing that quoted is the default natural syntax for identifiers, and that writing identifiers non-quoted is just a common supported shorthand for when that shorthand isn't ambiguous. ...
Isn't that the usual approach for SQL implementations?
It leads to abominations, such as column/table names like [cumulative salary taxable amount] when cumulativeSalaryTaxableAmount would be just as readable without festooning the code with eye-watering delimiters.
Quote from Dave Voorhis on December 22, 2024, 4:52 pmQuote from Darren Duncan on December 22, 2024, 5:34 amTo be clear, I'm proposing that quoted is the default natural syntax for identifiers, and that writing identifiers non-quoted is just a common supported shorthand for when that shorthand isn't ambiguous. ...
Isn't that the usual approach for SQL implementations?
It leads to abominations, such as column/table names like
[cumulative salary taxable amount]whencumulativeSalaryTaxableAmountwould be just as readable without festooning the code with eye-watering delimiters.
Yes, that is how SQL works, except typically it is quotation marks, eg "foo" for identifiers and 'foo' for regular character string data.
However, your counter example is even MORE of an abomination because there are no separators between the words and your casing is inconstant, making the first word all lowercase while capitalizing the others. The best names would be like cumulative_salary_taxable_amount, which both avoid the delimiters AND all the problems with your alternative.
Quote from Darren Duncan on December 22, 2024, 11:03 pmQuote from Dave Voorhis on December 22, 2024, 4:52 pmQuote from Darren Duncan on December 22, 2024, 5:34 amTo be clear, I'm proposing that quoted is the default natural syntax for identifiers, and that writing identifiers non-quoted is just a common supported shorthand for when that shorthand isn't ambiguous. ...
Isn't that the usual approach for SQL implementations?
It leads to abominations, such as column/table names like
[cumulative salary taxable amount]whencumulativeSalaryTaxableAmountwould be just as readable without festooning the code with eye-watering delimiters.Yes, that is how SQL works, except typically it is quotation marks, eg "foo" for identifiers and 'foo' for regular character string data.
However, your counter example is even MORE of an abomination because there are no separators between the words and your casing is inconstant, making the first word all lowercase while capitalizing the others. The best names would be like cumulative_salary_taxable_amount, which both avoid the delimiters AND all the problems with your alternative.
Ah, the eternal camelCase vs under_scores debate. All we need now is a good emacs vs vi argument (along with a dozen or so of the usual TTM forum quarrels) and the cycle will be complete.
Quote from Dave Voorhis on December 22, 2024, 4:52 pmQuote from Darren Duncan on December 22, 2024, 5:34 amTo be clear, I'm proposing that quoted is the default natural syntax for identifiers, and that writing identifiers non-quoted is just a common supported shorthand for when that shorthand isn't ambiguous. ...
Isn't that the usual approach for SQL implementations?
It leads to abominations, such as column/table names like
[cumulative salary taxable amount]whencumulativeSalaryTaxableAmountwould be just as readable without festooning the code with eye-watering delimiters.
If you want what would otherwise always be considered delimiters to be a legitimate token in a name, then you'll need other tokens to take over the delimiter role, or you'll need escape tokens.
cumulative\ salary\ taxable\ amount
could work too, with exactly the same downsides as Microsoft's ad-hoc [] syntax. (Or more and worse of them.)
Quote from Dave Voorhis on December 24, 2024, 10:29 am(along with a dozen or so of the usual TTM forum quarrels)
To be honest, I've really been missing those.
Quote from Erwin on March 24, 2025, 9:04 pm
If you want what would otherwise always be considered delimiters to be a legitimate token in a name, then you'll need other tokens to take over the delimiter role, or you'll need escape tokens.
cumulative\ salary\ taxable\ amountcould work too, with exactly the same downsides as Microsoft's ad-hoc [] syntax. (Or more and worse of them.)
This is a non-issue. We already have fully solved the problem comprehensively in the form of quoted and escaped-as-needed character string literals for character string data. Just reuse that core syntax for identifiers, and use context or some simple marker outside the quoted literal to distinguish the two when they even need distinguishing.
Quote from Darren Duncan on April 23, 2025, 8:57 pmQuote from Erwin on March 24, 2025, 9:04 pmIf you want what would otherwise always be considered delimiters to be a legitimate token in a name, then you'll need other tokens to take over the delimiter role, or you'll need escape tokens.
cumulative\ salary\ taxable\ amountcould work too, with exactly the same downsides as Microsoft's ad-hoc [] syntax. (Or more and worse of them.)
This is a non-issue. We already have fully solved the problem comprehensively in the form of quoted and escaped-as-needed character string literals for character string data. Just reuse that core syntax for identifiers, and use context or some simple marker outside the quoted literal to distinguish the two when they even need distinguishing.
Good for you. But whatever symbol you happen to pick as the quotation mark or as the escape token or as the "some simple marker", by definition of making that choice that symbol becomes a part of (the alphabet of) the meta-language and thus creates a new symbol that needs to be potentially escaped.
So the aim is (or might be) to allow the database designer total freedom in the choice of table names, column names, etc. The designer can choose select * from payroll where id like '%"%' as the name of the table produced by that query. So then the language needs a way to denote arbitrary strings of characters as identifiers, just to keep the parser happy.
Trivial. The result is a single token, marked out by start and end sequences. The only minor challenge is devising an end sequence in a way that it cannot appear inside the token. Here's one way to do it. If you don't like this one, I've got plenty more.
- "John O'Dwyer"
- @"John O'Dwyer"
- @/"John O'Dwyer"/
- @#/"John O'Dwyer/"#
- @\v~!@#$%^&*()_+John O'Dwyer-={}[]:";',./<>?\v
Quote from Erwin on April 24, 2025, 8:37 pmQuote from Darren Duncan on April 23, 2025, 8:57 pmQuote from Erwin on March 24, 2025, 9:04 pmIf you want what would otherwise always be considered delimiters to be a legitimate token in a name, then you'll need other tokens to take over the delimiter role, or you'll need escape tokens.
cumulative\ salary\ taxable\ amountcould work too, with exactly the same downsides as Microsoft's ad-hoc [] syntax. (Or more and worse of them.)
This is a non-issue. We already have fully solved the problem comprehensively in the form of quoted and escaped-as-needed character string literals for character string data. Just reuse that core syntax for identifiers, and use context or some simple marker outside the quoted literal to distinguish the two when they even need distinguishing.
Good for you. But whatever symbol you happen to pick as the quotation mark or as the escape token or as the "some simple marker", by definition of making that choice that symbol becomes a part of (the alphabet of) the meta-language and thus creates a new symbol that needs to be potentially escaped.
Erwin, I believe I was quite clear in saying that my proposal is just re-use for quoted identifiers the existing syntax for character string literals, exactly as is, same delimiters, same escape sequences, and so on. There are NO new quotation marks or escape tokens or whatever. That was the whole point, we don't need those things because we just use the ones already there as-is. So just as with the character string 'Foo', we can have the quoted identifier 'Foo'. Depending on the language syntax, context would tell us when encountering a 'Foo' whether it is meant to be an identifier or a regular literal, and in cases where it would be ambiguous, there could be some kind of simple syntax EXTERNAL TO THE STRING LITERAL to disambiguate that doesn't currently have some other legal meaning. For example, prefix the letter I for identifier, so eg I'Foo', or make it function-call-like eg I('Foo') or whatever, don't get stuck on this detail its just examples.