-
Notifications
You must be signed in to change notification settings - Fork 15
Description
Both issues #54 and #55 show that there's a desire to allow an inline dictionary or list on the same line as a key or list item. I also personally find the inline dictionary/list syntax to be somewhat ugly, especially in a list item, as it requires more vertical space than necessary.
I propose adding a new dictionary tag and list tag to mark the rest of the line as an inline dictionary or list. I tentatively propose using =␣ as the tag for both dictionary and list items. Other symbols (such as *␣ or +␣ or !␣) could be used instead, but that can be discussed and decided on later if this proposal actually gains traction.
Current syntax:
inline dict:
{this: is, a: dict}
inline list:
[this, is, a, list]
list:
-
{this: is, a: dict}
-
[this, is, a, list]
# the following is still a rest-of-line string
= : this is a dictionary item with a key of `=`
Proposed syntax:
inline dict= {this: is, a: dict}
inline list= [this, is, a, list]
list:
= {this: is, a: dict}
= [this, is, a, list]
# the following is still a rest-of-line string
= : this is a dictionary item with a key of `=`
(The current syntax with an inline dictionary/list on its own line will still be valid with this proposal.)
New parsing rule
The proposed new parsing rule is that if the new tag is followed by an opening brace/bracket and a matching closing brace/bracket at the end of the line, the rest of the line after the tag is parsed as an inline dictionary or list. Otherwise follow the current parsing logic (so that the new tag is simply another character in the key). This rule should minimize breaking existing Nested Text files.
Alternatively, don't check for a matching closing brace/bracket at the end of the line; it'll be a parse error (of the inline dictionary or list) if the closing brace or bracket is missing. This is IMO more user friendly as it won't silently parse the following as a key named a = {y but will fail with a parse error:
x = {y: z
Backward incompatibility
As far as I can tell, the only backward incompatibilities with this proposal are with items like this:
x = {y: z}
- = [1,2,3]
The first line is a valid but, dare I say it, pathological construct in the current syntax; it defines a key named x = {y with a string value of z}. But with this proposal it defines a key named x with a dictionary value of {y: z}. Does anyone name their keys like this? I don't know, but I'm guessing probably not.
The second line defines a list item with a rest-of-line string = [1,2,3] in the current syntax but a dictionary item with a key named - and a list value of [1,2,3] with the proposed syntax. This is possibly more likely to happen than the first case, but probably not often.
(Alternative dictionary and list tags like :*␣ and -*␣ might be more robust against backward incompatibility than =␣, but I'm sure they have their own cases of incompatibility, and one downside is that they make it more difficult to horizontally align the values in a group of dictionary or list items.)