Blank type annotations

[hkolbeck]

I'm starting to update kdl4j, and I ran across an edge case I thought I'd check feelings on. Right now you can specify a blank type annotation with ("")value. I don't see any reason implementations should deny that, but it's worth keeping an eye on for round tripping KDL.

[zkat]

I'm fine with this, tbh

[Patitotective]

I think blank type annotations are pointless, they just adds more complexity to the parser having to make represent them as Option types (since empty does not really mean no value).

[hkolbeck]

That's a good point. I'd propose having a blank string type annotation be explicitly equivalent to no annotation, with a test whose output has no annotation.

[Patitotective]

Ok, then, what would the way to propose this? a PR changing the tests?
Thanks for the answer.

[zkat]

yes

[larsgw]

I also think it's very unnatural for the KDL document

node

to result in

{ name: "node", tag: "" }

I think making node and ("")node equivalent adds unnecessary complexity to the language itself. I would be fine with disallowing zero-length identifiers altogether, but that doesn't solve the apparent complexity with dealing with null/Option (though I can't really think of a situation where that would be a big problem).

[Patitotective]

I'm making a parser for the Nim programming language and since I'm going to make annotations Option types, should I also make children Option types?

[zkat]

That one's up to you, but according to the proposed data model, which hasn't been merged yet, they should be treated as semantically equivalent. But this data model doesn't need to correspond to your concrete implementation, it's just a mental model of what KDL is supposed to mean.

So, the answer is it'll depend on the needs of your parser: for example, kdl-rs makes it an Option<KdlNode> type because it's a formatting-preserving parser and whether or not to have those {} actually matters.

[tabatkins]

And conversely, kdlpy does not make such a distinction - the children are just exposed as a list, and both an empty {} and no braces at all result in an empty list. It's not a formatting-preserving parser, however, and the distinction between the two cases doesn't seem meaningful in most cases. (Whereas an explicitly-specified ("") might actually be meaningfully distinct from no tag at all, so kdlpy uses str | None as the type for tags.)

[larsgw]

I agree. I'd argue that the tag equivalent to {} would be ()node, not ("")node. And that's already not valid (which makes sense to me). I guess node and node {} are a bit like <div></div> and <div />.

[tabatkins]

a bit like <div></div> and <div />.

Which, notably, are exactly equivalent in XML (they're just two syntax forms of the exact same DOM, and can be used interchangeably). ^_^