This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-09-17
Channels
- # announcements (1)
- # aws (7)
- # babashka (5)
- # calva (56)
- # cider (13)
- # clj-commons (1)
- # clj-kondo (12)
- # clj-yaml (35)
- # clojure (84)
- # clojure-europe (93)
- # clojure-sg (2)
- # clojure-uk (1)
- # clojurescript (10)
- # conjure (37)
- # core-typed (1)
- # cursive (31)
- # duct (1)
- # figwheel-main (4)
- # fulcro (2)
- # holy-lambda (2)
- # humbleui (3)
- # membrane (118)
- # off-topic (46)
- # pathom (8)
- # podcasts-discuss (5)
- # releases (2)
- # rewrite-clj (13)
- # sci (27)
- # shadow-cljs (17)
- # tools-deps (12)
Heya, starting to feel like I’m bogging down your https://github.com/clj-commons/clj-yaml/pull/38 @grzm!
I guess my main question is: do we really need/want to expose a snakeyaml constructor factory? My inclination is no.
trying to think of how tags should be exposed. As meta is probably the easiest way (though not all Yaml node values can take meta). tagged-literals would be another possible way. Then then question is how to translate the tag representation to a tagged literal representation. And I don't know what round-tripping would look like.
I'm sympathetic to the idea of not exposing snakeyaml implementaiton details. That said, the current options are already not ideal: you can provide both :unsafe and :mark keyword args, but they're not really fully orthogonal. (I'm trying to look past my dislike for keyword args: that'd be a version 2 change I'd like to see)
I suppose we could change tagged nodes to a map with :clj-yaml/tag
and :clj-yaml/value
keys (namespaced to ensure disambiguation with the data itself)
I'd like to see a full-on critique of EDN. Other serializations have such obvious flaws, but I'm sure I'm biased and blind to issues with EDN
re: :mark Oh, right. The examples in the README clearly show how the MarkedConstructor is supposed to be used. How'd I miss that?
The map thing might be a way forward. Questions about how to only change the ones that would otherwise fail…prolly try/catch or something…
Right now it just throws an exception with unknown tags, so (a) it's already broken and (b) any of this I'd see added as an option, like pass through but not throwing away anything.
So if you’d enabled parsing unknown tags, you’d be in a different mode where maps are returned?
(parse-string "!!bad-tag 3" {:read-unknown-tags true})
Might return?Maybe if we have an option where clj-yaml can return nodes instead of values? That might satisfy both :mark
and :read-unknown-tags
and also give you a richer return? I dunno, just throwing ideas out.
Forgetting about :mark
for a sec, and round-tripping, another idea would be to return separate warnings/findings. Ex. {:type :unknown-tag :row x :col y}
I wouldn't want a generic node one. I'm not against it, but my use case is that tags are the exception, not the rule.
Right. I guess we should step back and ask if it is important to know that an unrecognized tag was read. Round-tripping support would be one reason. As a user do you otherwise care?
We can always have documented limitations. Fine with me if they are reasonable to clj-yaml users.
Note: :mark
result is currently not directly round-tripable:
(def x (parse-string "3" :mark true))
(generate-string x)
;; => "start: {line: 0, index: 0, column: 0}\nend: {line: 0, index: 1, column: 1}\nunmark: 3\n"
@UE21H2HHD note that "don't bail on unknown tags" is the primary use case for the PR, which is just a feature coming over from another clojure library. That feature has been more or less directly ported. Since that feature worked fine in that other library, I was ok with the PR as is.
To limit exposure, we could change that to a toggle or so, to behave the same as with the explicit :constructor
.
off-topic:
I just had a "don't bail on unknown tags" problem for bb.edn
https://github.com/borkdude/quickdoc/issues/19