Clojurians Log v2

suppose I have a map like

{:id 1
   :label "the gizmo label"
   :type.id 5
   :type.label "the type label"
   :owner.id 8
   :owner.name "John Shutt"}

and I want to convert it to this format:

{:id 1
   :label "the gizmo label"
   :type {:id 5 :label "the type label"}
   :owner {:id 8 :name "John Shutt"}}

(i.e., a dot in the keys causes nesting, and I don't know any key names statically)

I have a few questions. first one: how do you accumulate into a map?

in plain Clojure this transformation would be:

(defn nest-dots
  [m]
  (reduce-kv
   (fn [m' k v]
     (assoc-in m'
               (map keyword (string/split (name k) #"\."))
               v))
   {}
   m))

(me/rewrite m
  {:id ?id
   :label ?label
   :type.id ?type-id
   :type.label ?type-label
   :owner.id ?owner-id
   :owner.name ?owner-name}
  {:id ?id
   :label ?label
   :type {:id ?type-id
          :label ?type-label}
   :owner {:id ?owner-id
           :name ?owner-name}})

It is possible to do something more generic like splitting on the dot etc. but the transformation language hasn’t matured enough to accommodate a clean way to do this.

thanks! yes, my use case would be definitely about splitting on the dot, since the transformation would have to handle keys not known statically

Accumulation/Aggregation is something that is planned for the next version of the library which I’ve been working on and hope to release sometime this year. The approach I’ve decided to take for the next version is completely different from the previous versions and is a complete rewrite of the library. Anyway, each of the variable types present in the current version can be seen as a type of memory with semantics for storage and retrieval. The plan is turn this observation into support for user defined types of variables.

If the number dotted keys you have is small and known, I would recommend to simply stick them in the pattern match.

In general, I often recommend this approach even if you’re not using Meander because it is obvious and almost always going to be faster.

To give folks a brief update on where things are at with zeta most of my time is still being split between 1. compilation, 2. testing, and 3. parsing. Compilation and testing are occupying the most time because, well, compilation is a faceted problem. At the moment, compilation speed has been my focus. Originally, the plan was, for compilation, to have a three step process: build the intermediate representation, optimize it, then turn it in to Clojure. Even though I was able to generate good code this way, the performance was poor due to the size of the trees being optimized. Now what I am doing is optimizing as the tree as it is being constructed to avoid this problem.

When I get the time later this year, I hope to write down a detailed explanation of how the internals are designed with the hope of being able to get more help from the community.

Once I’m confident that zeta meets the mark, I really want to starting spending more of my time using it rather than working on it.

I’ve long wanted to get back into tinkering with L-Systems and learning more about algorithmic botony.