meander

All things about https://github.com/noprompt/meander Need help and no one responded? Feel free to ping @U5K8NTHEZ
ikrimael 2020-07-22T04:44:38.149300Z

i have to say getting to not having to lookup syntax with meander is chefs kiss

ikrimael 2020-07-22T04:45:13.149400Z

it's making datashaping and refactoring a lot less of a chore (both in writing complex nested joins/extractions and being able to read it 5 days later instantly)

ikrimael 2020-07-22T04:47:56.149500Z

the current part i'm trying to unravel is how the memory variables work, specifically in the context of joins

ikrimael 2020-07-22T04:49:05.149600Z

--------------------------------- for ex, how to convert this into meander:

jimmy 2020-07-22T12:43:37.149700Z

At least for me, your example of what you want to convert does not show up here.

➕ 1
ikrimael 2020-07-23T06:10:17.156300Z

oops; forgot to actually paste

ikrimael 2020-07-23T06:12:11.156500Z

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)

ikrimael 2020-07-23T08:12:28.158Z

(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
   ))

ikrimael 2020-07-23T08:12:43.158200Z

so this is the problem distilled down

ikrimael 2020-07-23T08:13:50.158400Z

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

ikrimael 2020-07-23T08:17:14.158600Z

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

ikrimael 2020-07-23T08:20:03.158800Z

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

ikrimael 2020-07-23T08:20:47.159Z

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

jimmy 2020-07-23T14:05:42.160600Z

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.

noprompt 2020-07-22T19:32:13.152300Z

That’s great experience report to hear @e749 🙂

noprompt 2020-07-22T19:33:36.154Z

The 5 days later bit especially. In the early days when I was sketching out what I wanted to do that was one of the problems I wanted to address.

noprompt 2020-07-22T19:35:27.155900Z

Cause, you’re right, you often have to slow down, parse everything, and evaluate it in your mind when you come back to it. And it’s easy to end up with code like that when you’re in that “write only” mode, just trying to get an idea out of your head or some damn thing to work already.

☝️ 1