Fork me on GitHub

Did this get discussed on the mailing list at all?


The ticket doesn't really convey a strong sense of what is being solved to me, so I wonder if I am missing some context

Alex Miller (Clojure team)05:08:02

zip would absolutely have been a better design with protocols (if protocols had existed when it was created)

Alex Miller (Clojure team)05:08:11

I've written this same thing before

Alex Miller (Clojure team)05:08:34

but just because we can do it is not a strong argument for why we should do it

Alex Miller (Clojure team)05:08:05

perf is one possible reason

Alex Miller (Clojure team)05:08:30

oh, looking at the patch you're actually cutting a different dimension than I thought

Alex Miller (Clojure team)05:08:57

zippers themselves are a collection of 3 functions and I thought you were creating a protocol for that

Alex Miller (Clojure team)05:08:06

you've got all the functions buried under one protocol method

Alex Miller (Clojure team)05:08:28

I expected something like

(defprotocol Zipper 
  (branch? [this node]) 
  (children [this node]) 
  (make-node [this node children]))

Alex Miller (Clojure team)05:08:30

tying those impls to concrete types is bad b/c you might want different functions for the same type

Alex Miller (Clojure team)05:08:01

if dispatching on the concrete type was the idea here, I don't think it's a good one


Yeah, that is the other thing "protocolizing zippers" can mean different things, and this approach is the one I would expect the least

Alex Miller (Clojure team)05:08:24

yes, looking at the patch, I was surprised


You might check out something like

Alex Miller (Clojure team)05:08:33

even that is not what I'd expect :)


Although I guess that is all deftypes, no protocols


I feel like maybe bbloom had something

Alex Miller (Clojure team)05:08:56

but the argument being made in that is perf

Alex Miller (Clojure team)05:08:59

I wrote one way back when I wrote the zipper article in 2010/2011, but doesn't look I actually made a repo out of it

Alex Miller (Clojure team)05:08:39

but to unroll back to a good question - what problem are you trying to solve?

Alex Miller (Clojure team)05:08:52

what does this version do that the current version doesn't?


can Clojure loop constructs be unrolled by the JIT under any circumstance?

Alex Miller (Clojure team)18:08:11

they're pretty much the same as Java loops in the bytecode


I thought the JIT only unrolled counted loops (like for with a constant stride)?


the jit only sees bytecode, for loops don't exist in the bytecode


so what the jit can unroll are particular patterns of jumps in the bytecode


this might be nonsense but I’ll ask anyway: Maurizio Cimadamore mentioned in the Panama update from JVMLS that most loop optimizations don’t apply when using longs, am I correct that this would be an issue for Clojure loops as well since all primitive math is done with longs?


hah, it actually does seem to be the case: I have a Java loop with that gets unrolled when the loop variable is an int, but not when it’s a long, and the equivalent Clojure loop also does not get unrolled