Replies: 3 comments 8 replies
-
|
for tools (formatters, templating, etc.), you're going to need more than just comments in order to do a round trip:
And, the common case would be programs using KDL as a config file and such, which don't need to know about comments (and maybe shouldn't, to discourage putting data in comments?) but also all of this is kinda necessary for tooling. i'm not sure if that means a second parser, or feature flags, or a function to convert to the simpler format. probably depends on the implementation language? |
Beta Was this translation helpful? Give feedback.
-
|
All very good points! Another related question then is whether the spec should define some kind of standard for formatting a kdl document... |
Beta Was this translation helpful? Give feedback.
-
|
IMO an exact roundtrip is almost never required, because the use case is almost always creation of some canonical form. At least for quotes it seems like the canonical version would be the least-quoted one, which is what I did in the Java parser. |
Beta Was this translation helpful? Give feedback.
-
|
This is definitely an implementation concern, imo. For example, a serde-based parser might not want to deal with comments at all, since it only cares about data coming in, and would have some default way of dealing with data going out. What you're talking about is what I've heard called a "document-oriented parser", which would retain comment, spacing, and input format. I don't know if there's anything to do to allow this at the specification level, although I already made some decisions that require this type of parser for proper round-tripping for sure. But unless you're something as simple as JSON, this will usually be the case. |
Beta Was this translation helpful? Give feedback.
-
|
Just noting that I found this while trying to see if there was a way to view comments on a parsed Would you have interest in a PR that added support for Rust-style doc comments? Something like: types {
//! This is a module doc comment, and would be attached to the `types` node!
// this is a normal comment, not attached to any parsed nodes
/// This is doc comment, and would be attached to the `struct` node!
struct "Rgb8" {
/// This is a doc comment, and would be attached to the `r` node!
r "u8"
/// This is green
g "u8"
/// This is blue
b "u8"
}
}If there's interest, I can look into whether this would be feasible to support? From a standard perspective, I think it wouldn't interfere with anything, since there's no mandatory space character, so these would "just" be fancy line comments according to the spec. |
Beta Was this translation helpful? Give feedback.
-
|
Ah sorry, I missed that this was on the |
Beta Was this translation helpful? Give feedback.
-
|
I would say the same thing: kdl-rs doesn’t do any high level processing of comments right now. It treats them as whitespace. But you should be able to just throw another parsing layer at it as part of processing your IDL additionally: in your example, none of those strings need to be quoted in v2. I think that would make your DSL look nicer: types {
//! This is a module doc comment, and would be attached to the `types` node!<
8000
/span>
// this is a normal comment, not attached to any parsed nodes
/// This is doc comment, and would be attached to the `struct` node!
struct Rgb8 {
/// This is a doc comment, and would be attached to the `r` node!
r u8
/// This is green
g u8
/// This is blue
b u8
}
} |
Beta Was this translation helpful? Give feedback.
-
|
Yep, that was my ask: would you be open to grabbing the comments while parsing, and attaching them to re: the quoting, I definitely agree for builtins, some of the types use My full current test input (as well as the compiler itself) is here if you want to peek: https://github.com/jamesmunns/postcard-idl/blob/main/input/input-001.kdl |
Beta Was this translation helpful? Give feedback.
-
|
The comments are already grabbed by |
Beta Was this translation helpful? Give feedback.
-
|
I totally missed that the comments were parsed into the Format data. Thanks a ton! I'll take a look and see how I missed that. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
This is perhaps more aimed at implementations than the spec, but I think it would be really beneficial to have first-class support for comments in the APIs rather than them being silently discarded.
The main use would be when generating kdl strings from a program:
This raises questions:
Regarding comments in general, there's currently no concept of attaching comments to nodes, comments are just free. E.g. semantically or structurally, should there be a difference between these two below:
Beta Was this translation helpful? Give feedback.
All reactions