You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Then unparse map M into result sequence R: (unparse C M).
Expected:(is (= V R))
i.e. the roundtrip of parsing and unparsing V to M to R, should return the original sequence with items in the same order as the :catn definition.
Actual:(is (not= V R))
i.e. unparsing does not guarantee that the result sequence R will be in the same positional order of the original :catn schema C entries or of input sequence V.
It seems to depend on the arbitrary order of the hash map that typically varies by its size, which suggests unparse applies to the seq of entries of map M. So small maps misleadingly seem to hold that (is (= V R)) by coincidence.
Other seqexp schemas like :* or :altn seem to preserve the order of the input value to unparse (rather than schema entry definition order), so maybe the order lossiness of :catn parse-unparse roundtrips is actually consistent in principle and should be expected.
If so, then it would still be interesting to have some other builtin schema to achieve the expected roundtrip behavior of this issue. Maybe a named-tuple or ordered-map type of schema (:catns?) as a terser form of the workaround above returning a MapEntry sequence preserving order.
The text was updated successfully, but these errors were encountered:
Steps:
:catn
schema C,parse
a valid sequence V into map M:(parse C V)
,unparse
map M into result sequence R:(unparse C M)
.Expected:
(is (= V R))
:catn
definition.Actual:
(is (not= V R))
:catn
schema C entries or of input sequence V.Example at JVM Clojure REPL:
Workaround using
:cat
+:orn
:Comments
It seems to depend on the arbitrary order of the hash map that typically varies by its size, which suggests
unparse
applies to theseq
of entries of map M. So small maps misleadingly seem to hold that(is (= V R))
by coincidence.Other seqexp schemas like
:*
or:altn
seem to preserve the order of the input value tounparse
(rather than schema entry definition order), so maybe the order lossiness of:catn
parse-unparse roundtrips is actually consistent in principle and should be expected.If so, then it would still be interesting to have some other builtin schema to achieve the expected roundtrip behavior of this issue. Maybe a named-tuple or ordered-map type of schema (
:catns
?) as a terser form of the workaround above returning a MapEntry sequence preserving order.The text was updated successfully, but these errors were encountered: