-
Notifications
You must be signed in to change notification settings - Fork 96
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
Alternative string quote syntax #84
Comments
Further inspiration: Chicken Scheme multiline strings https://wiki.call-cc.org/man/4/Non-standard%20read%20syntax#multiline-string-constant |
Eg. of the Chicken Scheme syntax: (define msg #<<END
"Hello, world!", she said.
END
) Personally I've never liked how the closer for heredocs have to span the whole line, You end up having to push any closing brackets or other constructs to the line after and it always looks unnatural to me 😞. |
I mean, you could theoretically specify that the closer does not have to span the whole line, of course. "The closer is everything up to the first closing parenthesis" or something. |
True. And I guess in a way, XML's CDATA tag takes this even one step further, at the cost of not letting you customize the closer, opening with |
After spending considerable time comparing string literal syntaxes across languages, here are my assessments:
Note: I could have phrased my comment more neutrally, but that would be hiding my bias. (My bias may or not be useful to you, so interpret it accordingly.) My assessment is informed by wrestling with tradeoffs in this space while designing a new human-readable interchange format. |
I would like to chime in with an idea I have recently had. A multiline string might begin with a backslash character, followed by blank space and then a line limiter. Subsequent lines would have some blank space at the beginning, then a backslash character. The rest of the line including the new line would be part of the multi-line string. The first line that doesn't start with a pipe character is not included and parsing continues as normal. The first and the last new line characters in the multi-line string are always removed. Examples:
Becomes
If alternative interpretations of the multiline string are needed, they can simply be dispatches. For example, This makes several different types of multiline strings possible with a simple syntax that is easy to understand and remember. It also allows you to embed one document inside another without escaping anything inside that document. All you have to do is prefix all the lines in the document with some space and a pipe. The ability to embed documents inside other documents is a killer feature for configuration languages. Being able to add it simply to edn like this would be amazing. |
Evidently there's been a discussion about this in clojure (almost 6 years ago) but there wasn't an issue for this in the edn spec so here's one.
So far the only syntax for strings is with speech marks
"
as delimiters. This makes writing strings that contain"
a chore because you have to escape them at every occurrence. It also makes it harder to tell where one argument begins and another ends because no white space is needed to separate arguments.Suffice it to say escaping quotes hurts readability when quotes are used in abundance. This also affects JSON. I recently started using edn to configure my dotfiles so I've been writing quite a bit of shell script in edn and this is the sort of stuff I keep having to deal with.
The discussion I've linked to above described 3 alternatives, hopefully this issue opens a dialogue and gets the ball rolling on how best to tackles this problem.
Personally I quite like the triple quote python approach.
The text was updated successfully, but these errors were encountered: