-
-
Notifications
You must be signed in to change notification settings - Fork 36
Use "
or '
instead of |
as quote delimiter
#414
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@@ -47,12 +49,15 @@ unquoted-start = name-start / DIGIT / "." | |||
reserved = ( reserved-start / private-start ) reserved-body | |||
reserved-start = "!" / "@" / "#" / "%" / "*" / "<" / ">" / "/" / "?" / "~" | |||
private-start = "^" / "&" | |||
reserved-body = *( [s] 1*(reserved-char / reserved-escape / literal)) | |||
reserved-body = *( [s] 1*(reserved-char / reserved-escape / quoted)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an unrelated fix that I noticed while working on this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please make a separate PR for this.
The intention was to allow reserved
to define whatever structure it wants. For example, allowing "comments" might look something like:
{% This is a "comment". Do not translate it}
{$foo % This is a "comment" about $foo: do not translate it}
The contents of reserved
must appear within a placeholder, so the characters {
and }
must be escaped--but everything else (including quotes, whichever ones we use) remain undefined.
Hence reserved-char
should match text-char
. The production reserved-char
currently omits whitespace, but the optional whitespace part of reserved-body
just adds the spaces back.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done: #415.
(as contributor): However, I note that our syntax will be embedded into file formats (I cited JSON in the #263 thread) or into code. These syntaxes already use (as chair): |
I think I understand @eemeli’s position, but my current view is to oppose this change. The premise of the presented argument seems to be that the current delimiter syntax is unusual. That’s true, but more crucially, I’d say our unquoted literal syntax is even more unusual. So we’re already in the realm of “weirdness”, and extending it a bit by choosing We expect quotes literals to be rare. We tend to give two corollaries from the rareness argument, which contradict each other:
I think that just looking at these two points of view won’t lead us to a consensus. That’s where trade-offs and use-cases come into play. Using regular quotes as delimiters comes with a cost: embedding into most other programming languages and container formats will require caution. Using exotic delimiters prevents this one class of issues. Exotic syntax is OK if it’s well justified. I think users will understand and learn to use it. |
I 100% agree with the "weirdness" part. But I think the original reasons for
And since none of that changed, I would not change this. TLDR: same concerns as Addison & Stas |
+0. Voicing pure neutrality on this one. This is 🎨 . The OCaml'er and pgpsql'er in me is fine with the pipes. The more common lang developer in me (TS, rust) is fine with the quotes. We're in a DSL. I like to think that consumers of DSLs have a natural intuition of "DSL rules apply here, not my own presumptions", ...but given the correlation/pairing that MF2 has with programming concepts, it's a nice byproduct to have literal grouping aligned between paradigms. |
Converting this to draft until #477 is eventually accepted, at which point this can be rebased or abandoned. |
Closed per telecon of 2023-11-27 |
Please see the following discussions for context on how we ended up with
|quotes|
:Now that we've made it possible to use unquoted values as operands, I realise that my opinion on this topic has changed, and so I'm proposing that we allow both
'quoted'
and"quoted"
literals. I have three reasons for this:{42 :number}
, I'm much less bothered by using string-y quote characters for delimiting literal values. In particular, if/once we also allow for negative numbers to not be quoted.|
as literal delimiters (or()
before the current choice) is really rather novel, and that's not really a good thing.'
or"
should reduce the need to escape these delimiters either due to characters in the literal value, or due to the delimiters of a surrounding resource format.As one negative consequence of this proposed change, this might mean a little more care is necessary when moving the source of a message from one encapsulation to another one. I think this is well justified given the benefits.