Hey @zane, I'll take a peek and see what problem cljdoc is having here.

The https://repo.clojars.org/meander/epsilon/0.0.650/epsilon-0.0.650.pom does not point back to meander sources on GitHub.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="" xmlns:xsi="" xsi:schemaLocation=" ">
  <modelVersion>4.0.0</modelVersion>
  <packaging>jar</packaging>
  <groupId>meander</groupId>
  <artifactId>epsilon</artifactId>
  <version>0.0.650</version>
  <name>epsilon</name>
  <dependencies>
    <dependency>
      <groupId>org.clojure</groupId>
      <artifactId>clojure</artifactId>
      <version>1.10.3</version>
    </dependency>
  </dependencies>
  <build>
    <sourceDirectory>src</sourceDirectory>
  </build>
  <repositories>
    <repository>
      <id>clojars</id>
      <url></url>
    </repository>
  </repositories>
</project>

Cljdoc https://github.com/cljdoc/cljdoc/blob/master/doc/userguide/for-library-authors.adoc#git-sources`<scm>`https://github.com/cljdoc/cljdoc/blob/master/doc/userguide/for-library-authors.adoc#git-sources. Older versions of meander published to clojars do have some <scm> info so, the build process probably changed. And meander does have a doc/cljdoc.edn to there has been historical interest in cljdoc.

Er, rather the link isn’t broken, but the page it takes you to is.

Thanks for looking into it, @UE21H2HHD!

Oh @zane, I think I maybe misunderstood, I thought you were noting that the articles did not import on cljdoc, and that's what I looked into.

That is what I noticed! Sorry for the confusion.

Oh good. Same page then!

I was just trying to clarify what was probably already clear from the screenshot: That the link successfully takes you to a webpage, but that the webpage has problems.

Should we raise an issue on meander repo?

Sounds good!

Oh https://github.com/noprompt/meander/issues/236, I'll add some details.

You want to rewrite everything in the top level and also everything one level down? I might just thread through two rewrites.

Yes, that’s correct. Can you explain what you mean by “thread through two rewrites?” The cleanest method I can come up with involves mapping over the repeated key’s value with a secondary meander/match call. But that just seems wrong. Here’s the rough shape:

(meander/match input
	       {:a [!nested ...]}
	       {:A (mapv #(meander/match %
					 {:b ?b :x ?x :y ?y}
					 {:B ?b :x ?x :y ?y})))

Hmm. What I had in mind didn't work when I actually tried to write code. I was thinking thread-first -> through m/rewrite for :a to :A and then again m/rewrite to turn {:A [{:b ... into {:A [{:B ...

This probably isn't what you want but I still don't understand what you want.

(m/rewrite {:a [{:b 1 :x 3}
                {:b 2 :y 4}]}
  {:a [!a ...] & ?rest}
  {:A [(m/cata !a) ...] & ?rest}
  {:b ?b & ?rest}
  {:B ?b & ?rest})

gives {:A [{:x 3, :B 1} {:y 4, :B 2}]}

m/cata recurses on each thing. If there's another :a there then it'll get matched. that's probably not what you want.

Is this the kind of thing you are looking for?

(def input {:a [{:b 1 :x 12} {:b 2 :y 13}]})

(m/rewrite input
  {:a [{:b !bs & !xs} ...]}
  {:A [{:B !bs & !xs} ...]})

;; =>
;; {:A [{:x 12, :B 1} {:y 13, :B 2}]}

In words, I want to transform a map containing a sequence of maps at some key. I see how to transform a map with a sequence at some key, but if the sequence is composed of maps then I see no way to modify the child maps without a second invocation of meander. It seems weird that nested data structures can’t be “described” sufficiently to allow this. Again, here is the shape of the input:

{:a [{:b 1} {:b 2}]}

{:A [{:B 1} {:B 2}]}

@U5K8NTHEZ, I need to study your solution -it looks very close to what I need.

Unfortunately, I think the problem with that solution is that it treats the subsequence as a memorization (= memory variable) and AFAICT there is no means to correlate memory variables. A slightly extended example shows how that approach will come up short:

{:a [{:b 1 :c 3} {:b 2 :c 4}]}

{:A [{:B 1 :C 2} {:B 2 :C 4}]}

With memory variables, I don’t think it is possible to retain the correlation of 1 and 3 in the first inner map (and similarly for 2 and 4 in the second inner map). My expectations might be unreasonable: I was expecting equivalent transformation power on nested repeated data as on the top-level data. Perhaps invoking meander twice is the best option.

(m/rewrite {:a [{:b 1 :c 3} {:b 2 :c 4}]}
  {:a [{:b !b :c !c & !xs} ..!n] & ?rest}
  {:A [{:B !b :C !c & !xs} ..!n] & ?rest})
;; {:A [{:B 1, :C 3} {:B 2, :C 4}]}

I'm confused on the output.

{:b 1 :c 3}
;; turns into 
{:B 1 :C 2}

Assuming it is a typo

(m/rewrite input
  {:a [{:b !bs :c !cs & !xs} ...]}
  {:A [{:B !bs :C !cs & !xs} ...]})

Yep, it was a typo.

So yeah. That seems to work. There are ways to correlate memory variables more specifically but I don’t see the need for that here. So I must be missing something.

So that ^ shows that the memory variables are being “consumed” in parallel and maintain the correlation of the map entities.

Nice.

Not at all obvious, but nice.

Yeah you can do some fancier things with different repeat operators. But in general they do one value for each repeat. So for the same length things they should be fine.

@U5K8NTHEZ and @UPD88PGNT, thanks for your help with this. I’ve got additional requirement that I fear may break the solutions you have proposed… I need each of the subordinate output maps to include the index of the subordinate input maps. So using @UPD88PGNT’s example from above:

(m/rewrite {:a [{:b 1 :c 3} {:b 2 :c 4}]}
  {:a [{:b !b :c !c & !xs} ..!n] & ?rest}
  {:A [{:B !b :C !c & !xs} ..!n] & ?rest})
;; {:A [{:B 1, :C 3 :index 1} {:B 2, :C 4 :index 2}]}

Not at my computer. I’ll have to think about index. But I can confirm for sure that the “correlation” isn’t accidental. The way memory variables work is just conceptually push and pop into a vector.

For index, I am sure there is some other way. But this was what I first came up with for doing it.

(m/rewrite {:a (map-indexed vector [{:b 1 :c 3} {:b 2 :c 4}])}
  {:a ([!index {:b !b :c !c & !xs}] ...) & ?rest}
  {:A [{:B !b :C !c :index (m/app inc !index) & !xs} ...] & ?rest})

defn add-index [coll]
  (into []
        (map-indexed
         (fn [i x]
           (assoc x :index (inc i))))
        coll))


(m/rewrite {:a (add-index [{:b 1 :c 3} {:b 2 :c 4}])}
  {:a [{:b !b :c !c & !xs} ...] & ?rest}
  {:A [{:B !b :C !c & !xs} ...] & ?rest})

THanks. I agree: some pre- and post- processing to add content is OK.