Lift restrictions on property names by using a pair of characters around identifiers (only when necessary)

[LeaVerou]

While using Coda, I noticed something quite nice about its formula syntax. They allow names to contain any character, and just reserve a pair of characters ([] in Coda) to surround identifiers that contain special characters. They obscure these in the UI, but you can see them by copying a formula and pasting it as plain text.

For example, here's a formula to calculate time spent on a project, in a time tracker:

[Time tracker].Filter(Activity = thisRow).[Time spent].sum()

and here’s how it’s shown in the UI:

Note that they only use the brackets when necessary: Activity or thisRow do not need any.

We know from our user studies that restrictions around identifiers are a very common pain point, especially for non-technical users (like the ones that tried Lifesheets).

I think it would be pretty easy technically to implement something like this, the question is what pair of characters to use.

Non-viable options

• We cannot use ( ) or ""/'' as that conflicts with existing syntax
• <> conflicts with HTML

Potentially viable options

• []. Since we already use [] for expressions that are interspersed with content, we'd first need to switch that to something else, such as {} or the more common {{ }}).
  • We chose [] for expressions because it was more readable, and looked less "geeky" than {{ }}, but people often wanted to use the more standard {{ }} and brackets conflicted with regular content more often.
  • The main downside is that this is a huge departure from existing syntax, we'd need to convert everything (initially by just adding mv-expressions="[ ]" to it).
• { } is currently free I think, but it means we can never introduce JS-like blocks
• [[ ]]. Not a fan, too clumsy and verbose, especially together with [ ].
• Some entirely new character that's not already seen as part of a pair, e.g. |. Though the containment introduced by a pair is quite nice and aids readability.
• A character before a pair that's not a viable option by itself, e.g. #(). Too geeky?
• A functional notation, e.g. id()
• Backticks (`). Downside is that we're using a symbol with meaning in JS, with a different meaning.

The example above with each of these options:

[Time tracker].Filter(Activity = thisRow).[Time spent].sum()
{Time tracker}.Filter(Activity = thisRow).{Time spent}.sum()
[[Time tracker]].Filter(Activity = thisRow).[[Time spent]].sum()
|Time tracker|.Filter(Activity = thisRow).|Time spent|.sum()
#(Time tracker).Filter(Activity = thisRow).#(Time spent).sum()
id(Time tracker).Filter(Activity = thisRow).id(Time spent).sum()
`Time tracker`.Filter(Activity = thisRow).`Time spent`.sum()

[joyously]

My opinion is that overloading some sort of bracket just to allow arbitrary naming is not a good trade-off, especially if you have to change existing expressions. The existing usage was chosen as best option for the feature set implemented, so to go back and change it leaves both features as less than optimal.
Would it work with backslash before the offending character? Or a function that removes characters before using the name in the expression?

[DmitrySharabin]

Backticks? Or is it too much for HTML/CSS developers? Or is it not very readable?

`Time tracker`.Filter(Activity = thisRow).`Time spent`.sum()

[LeaVerou]

Backticks? Or is it too much for HTML/CSS developers? Or is it not very readable?

`Time tracker`.Filter(Activity = thisRow).[Time spent].sum()

I don't think it's too much, I think a bigger issue is that it's used in JS in a different way, so it makes expressions confusing to read to those who do understand JS. But many options have this problem. I added this as an option to consider.