Clojurians Log v2

oops; forgot to actually paste

sigh, now I forgot the exact context which I was asking around. let me circle back after I hit it again (won't be long since it's a top 3 pattern I keep hitting)

yeah. i'm a big believer in "stop forcing devs to play compiler/computer in their heads"

(m/match
 [{:type   "Operator"
   :fields [{:type "int32" :name "age" :meta [[:uiSlider 1 100] [:tooltip "MyTool"]]}
            {:type "uid_t" :name "id"  :meta [[:hidden]]}]}
  {:type   "Graph"
   :fields [{:type "vec<int32>" :name "nodes" :meta [[:hidden]]}
            {:type "graphDesc"  :name "meta"  :meta [[:hidden]]}]}]

  [[{:type !type :fields ?flds} ...]]
  (;; Can't use meander syntax to rewrite/pattern match inside of ?flds and have to resort to let destructurings
   )
  
 [[{:type !type :fields [{:type !fldtype :name !fldname :meta !meta}  ...]} ...]]
  (;; !fldtype,!fldname,!meta are no longer "grouped" together to the type they were in
   ))

so this is the problem distilled down

what I "discovered" last night is using (m/cata) to recurse down and creating a pattern match term for each "nesting level"

it's a decent compromise but i'm left wanting: - separating out to different terms erases context of which nested terms are allowed to appear where - found it harder to debug, both along user syntax errors and logic. What i'd end up doing is replace each pattern match term one by one starting from the top until i found which nesting level had an issue, then proceed from there

some mitigations to issues above: - discovered datawalk which has been a godsend and made the above process a lot less painful - since the nesting match terms are all together, it's not that bad. instead of instant grokking of the code, maybe it's 5-10 mins as one mentally reconstructs which terms are allowed to go where

as a real world ex: here's the code from last night: https://gist.github.com/ikrima/0353f3f1600a639797c63b2692c63334

Given the code below -

(m/search [{:farm ""}
           {:farm "a"}
           {:farm ""}]
  (m/scan {:farm _ :as ?row})
  (assoc ?row :farm "b"))

Here are two other ways you could write this:

(m/rewrite [{:farm ""}
            {:farm "a"}
            {:farm ""}]
  [{:farm _ & !rest} ...]
  [{:farm "b" & !rest} ...])


(m/rewrites [{:farm ""}
             {:farm "a"}
             {:farm ""}]
   (m/scan {:farm _ & ?rest})
  {:farm "b" & ?rest})

I'm not 100% sure I followed all of what is going on. I think from what I do understand that you are probably doing the right thing by using cata. That is how we often deal with complicated patterns that need a fresh context for nested matches.

(m/search [[{:a 1} {:c 3}] [{:b 2} {:d 5}]]
  (m/scan [{:as ?row}])
  (assoc ?row :z 1))

(m/rewrites [[{:a 1} {:c 3}] [{:b 2} {:d 5}]]
  (m/scan (m/scan {& ?rest}))
  {:z 2 & ?rest})

@jimmy thanks, let me try to wrap my head around rewrite/rewrites, when do I use it, it looks very similar to match/search ?

So both rewrite and rewrites use m/subst on the right hand side. If you think about pattern matching as deconstructing values, substitution is the constructing of values. Basically it extends many of meanders features for creating things as well as matching on them. To make it concrete, instead of rewrites I could have just said:

(m/search [{:farm ""}
             {:farm "a"}
             {:farm ""}]
   (m/scan {:farm _ & ?rest})
  (m/subst
    {:farm "b" & ?rest}))

cool thanks

(m/rewrite [[{:a 1} {:c 3}] [{:b 2} {:d 5}]]
  [(m/cata !xs) ...]
  [!xs ...]

  {:as ?it}
  {:z 2 & ?it})
;; =>
[[{:a 1, :z 2} {:c 3, :z 2}] [{:b 2, :z 2} {:d 5, :z 2}]]

@murtaza52 ☝️

One rule to rewrite vectors (recursively rewriting their members), and one to rewrite maps.

Meander has some built-in resistance to complex movements, in particular update “in place”. If you find yourself trying to figure out how to do a transform in one fell swoop, break it up in to more focused rules and use m/cata to drive the traversal, etc.

Hey folks, I’ve pushed up the some work I’ve been doing to make it possible to dynamically create pattern search interpreters. https://github.com/noprompt/meander/pull/128

It’s not quite ready to merge. In the spirit of including the community to the extent I can, I’m welcoming feedback both here and on the PR.

It’ll at least be another couple weeks before this will get merged. In the mean time I plan to address the regression recently pointed out and smooth out any rough edges I see.

Questions are welcome. I know some have mentioned a desire to understand how the semantics are implemented in code and I said that I think an interpreter can help with that. If there’s still confusion, I’m happy to walk through it.