Fork me on GitHub

that's close but not quite it. the keys need to match in both. in your example there is no correspondence between structure-1 and structure-2 since the keys do not overlap


i was thinking of a zipping the two structures into a sequence where each entry is a three-tuple of the following form: [materizlied_path, value_one, value_two] where either value_one or value_two could be nil when that structure does not have an entry for a specific path that the other one does.


then the satisfies would make sure that no nil entries exist in any of those slots for my particular application

Joshua Suskalo15:09:02

Ah, that was unclear from your initial description of the problem. I don't believe specter has a way for you to get a pair of the actual path followed along with the value, which means you would likely need to generate a list of possible paths and iterate over them manually.

Joshua Suskalo15:09:29

Specifically, you could have a way to generate a "materialized path" from each of the types of navigations which navigate to multiple items. Like ALL generating a sequence of paths with nth being called for each integer in (range 0 (count structure)), or MAP-VALS generating a sequence of the keys.


Pretty sure it wasn't "unclear from my initial description". Please re-read. Pay particular attention to: a) verify that the same key structure exists in both


Ok, yes looks like a challenge wrt generating (or iterating) the paths but that seems surmountable.


Thanks for your help!

Joshua Suskalo19:09:24

No problem! Might just be I read that different because even on re-reading it didn't seem clear to me. Definitely not a huge concern though, it got worked out! 🙂


btw, i just realized that i already have this keys-in function in my codebase (based on tree-seq), so i probably don't really even need specter for this:


i can just get the key sequence paths for m1 and then call get-in for each of them on m2

👍 2

arguably not nearly as elegant as whatever the specter solution would be tho 🙂


Q: I’m using a multi-path in a recursive path similar to this example I just discovered that my multi-path expression is working on jvm but not on javascript. The problem seems to be that I have 20 values in the multi-path. has anyone seen a limit of 20 in paths failing like this before?


I also discovered that 21 values in multi-path fails on cljs with “invalid arity” but not on jvm


workaround: compose the multi-path out of other multi-paths


the bug is that the 20th entry is ignored when used in cljs. if there’s 19 entries then it is fine


asking here before I log a bug, just so I know I’m not missing something stoopid


@U173SEFUN do you care about edge case bugs like this?


i highly doubt that resource limitations of modern computers really justify that maximum being 20. probably could be just fine with 127 or 1023


and way more generous to users


just to throw my two cents in


@U0510KXTU please file a bug report


roger that. will do