what's wrong with my implementation of a take-nth navigator: https://gist.github.com/luxbock/a6a1323497a02e36b09dec624c57b3ab ?

I am using (:refer-clojure :exclude [take-nth]) so it's not colliding with the clojure.core version

using transform works fine

argh, I'm an idiot, of course I'm calling take-nth inside my select*

if I want my navigators to respect NONE do I need to implement that for every navigator?

@luxbock yes

is that something that could be done automatically for me, or am I missing something obvious?

how to handle transformations to NONE is completely navigator specific

for keypath it does a dissoc, for ALL it filters it from reconstruction, for nthpath it removes from the sequence, etc.

right, makes sense

looking at how those navigators implement it would be instructive I think

what is the extra argument vals that defrichnav uses for select and transform?

those are the collected values

like from collect, collect-one

ah I see, thanks

navigators that need to be defined using defrichnav are special cases

keypath does it as an optimization since Clojure/JVM aren't smart enough to inline this particular case

I'm trying to figure out how I could implement every-nth that respects NONE but it feels very difficult: https://gist.github.com/luxbock/69b766830144e4bdb767923ba7fb2f9c

you'll need a totally different approach

better to construct a new vector from scratch

elements that aren't at the nth indices go in unchanged, and for the others you apply next-fn and filter out ones that transform to NONE

something similar for lists

that's basically how ALL works

yeah, I'm trying to learn from the specter native navigators but they are so heavily optimized that it's taking some time 🙂

ALL on vectors is pretty simple https://github.com/nathanmarz/specter/blob/master/src/clj/com/rpl/specter/navs.cljc#L94

you should be able to do something very similar

yeah, I'll keep trying, seems like an appropriately challenging example for me to level up on

lists are a little trickier due to needing to maintain order https://github.com/nathanmarz/specter/blob/master/src/clj/com/rpl/specter/navs.cljc#L71

looks like you're understanding how navs work pretty well

do you see specter still adding more navigators (such as these) or would you rather people see publish them as utility libraries?

I think it's easy enough to write navigators that are very naive, but making them highly performant, versatile (in support for all possible datastructures) and respecting NONE is a lot of work, so I would definitely be happy to share the workload with others

I remember a while back you mentioned that transducers that use comp are in some cases slower than just writing the same tranformation sequentially, because of the overhead of comp, and you could improve the performance by pre-compiling the composed transducer

how would one compile a transducer, if I already know what it should do and don't need to compose it further using other transducers?

this seems to work and looks a lot better: https://gist.github.com/luxbock/33fecd25fce1ea91412ff86fb4df1e83

@luxbock these don't seem core enough to me to go into specter core

also some of these may be superseded by stateful navigators if that's ever implemented https://github.com/nathanmarz/specter/issues/121

not sure I understand your question about transducers

you precompile by calling comp in a central spot

the problem is you can't precompile anything that requires the dynamic context (like local variables)

e.g. (comp (map some-local-arg) (filter even?))

the best you can do is precompile sequences of static transducers for reuse

in theory, transducers could use a similar inline compilation/caching strategy as specter to make this automatic

I see, yeah stateful navigators look very interesting