amosA parser library (JSONC, YAML, TOML) should optionally let you parse comments — what you do with them is your prerogative.
Yes, your job is to parse
No, throw comments away
It's complicated
Poll ended at .
kouhai, of the health issues@fasterthanlime comment-preserving editing library, or
TheConstructor (he/him)@fasterthanlime I most often ignore them, but sometimes I want to update a value while keeping the comments intact
Psentee@TheConstructor @fasterthanlime this is a common use case for me, but in that case it’s a lot wider: it’s „keep all formatting intact, whitespace and indent and all, including comments”. Comments are just a part of keeping the meaningless formatting intact.
A parser/serializer that lets me make programmatic semantic changes to a file created and edited by humans without mangling it and generates a minimal text-level diff is *golden*.
Rasmus Hansen@fasterthanlime for some good horror, checkout the "containerless bindings" that knockoutjs has: https://knockoutjs.com/documentation/if-binding.html
(And yes, that webpage is probably as old as you think it is)
Lars Marowsky-Brée 😷@fasterthanlime It's been a sense of frustration for me that most parse-serialize cycles (e.g., automated changes to the config file) don't really treat comments well. (Mostly they get thrown out.)
jcoglan@fasterthanlime the main use case for this is preserving comments and formatting when editing, so you would also need to preserve formatting and then the kind of thing your parser returns becomes very different. I don't think encouraging use of comments to convey information to the program is a good idea either
Soso@fasterthanlime I'm think I'm on the side of "it complexifies the API for users and makes maintenance harder, and is rarely useful", so IMHO if the maintainer doesn't need it/doesn't want to maintain this it's fine and in the rare cases it's needed can be served by a dedicated (editing) library that also tracks spans etc...
Julien Roncaglia@fasterthanlime IMHO as long as it doesn’t slow down or affect the API of the no-trivia version, having a trivia-preserving mode with a similar API is cool. But it’s a too rare usage case to lose anything over.
@fasterthanlime oh and it should be full trivia and format, so array or string style in YAML (no quote, single quotes, double quoted or folded style string…), line breaks, end of line whitespace… all trivia necessary to edit one field and have only that line appear in a diff.
Comment only seems a lot less useful.
Comment only seems a lot less useful.
M. J. Fromberger@fasterthanlime Designing an API that can round-trip decorations and layout is a much more complex problem than merely parsing, and involves some tradeoffs you may not always want (particularly around memory use and throughput). With care, some of the underlying machinery may be shareable between "fast path read-only" and "accurate round trip", but often less than you'd hope. Grafting on a decorated representation after the fact usually results in a mess. And it's not well-trodden with theory.
Kantor@fasterthanlime encouraging parsing comments and interacting with them in the program will let some people to use them as schema extension and that's not good.
Sean Hood
Wanja@fasterthanlime There are a few perfectly valid uses for parsers give you comments, e.g. for syntax highlighting and other IDE-ish tasks. So I'd say yes, offer it optionally. However, you can sometimes write a way simpler or faster parser if you can just ignore them ASAP, therefore it's complicated.
J. Cliff Dyer@fasterthanlime
Not all parsers need comments, but if I'm going to use a parser *library*, I don't want to have to learn a whole other tool when my requirements change to require comment preservation.
Not all parsers need comments, but if I'm going to use a parser *library*, I don't want to have to learn a whole other tool when my requirements change to require comment preservation.
Ed Page@fasterthanlime I feel like context is important on this. iiuc this is about whether to do this for a serde-like API and would only track comments and not general formatting. There is also the large question of how comments get associated with a value.
@fasterthanlime Full format preserving on edits is non-trivial and should generally handled separately from other parsing.
If you are working with a serde-like API, then it is very complicated to carry forward all formatting. This is especially true for formats with more flexible styling like yaml and toml. For example in toml, you have 3 different ways to define tables and sort order is a cross-table concern.
Whether you do serde-like or work with a Value that has the logical structure, there is a major performance impact to carry forward formatting. In a serde-like API, it is also quite invasive on your types.
Markus Unterwaditzer@fasterthanlime it's complicated and depends on whether i need the parser to be really fast and memory efficient.
Paul Hansen@fasterthanlime I'm late, didn't vote, but here's my use case in favor of them.
I run a game server hosting site (full stack Rust) where users edit game config files in a nice web gui or edit the files directly. Games often have comments in their default config files to explain what the values do. If editing from the GUI strips those, then it makes editing the file a lot more confusing for users (e.g. when they need to edit a field we haven't added to the gui yet).
@fasterthanlime Additionally if parsers support reading comments, we can build tools for initially populating the help text for our web gui with them which saves a lot of manual copy pasting. (Some games have literally hundreds of settings)
@paul so that's a middle-ground between "throw away comments" and "allow re-serializing down to the exact same whitespace/comment location/etc." ?
@fasterthanlime For our use case I probably would prefer if it kept all formatting and ordering. Sometimes the grouping of settings helps with context etc., but I probably wouldn't bother writing my own parser if there was an existing one that kept comments and lost some formatting.
So yeah, kind of middle ground, but would still get some value out of full preservation too.