Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2019-08-07

Channels

#clojure-dev
<
2019-08-07
>
hiredman05:08:32

Did this get discussed on the mailing list at all?

hiredman05:08:40

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

hiredman05:08:06

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

hiredman05:08:41

You might check out something like https://github.com/akhudek/fast-zip

Alex Miller (Clojure team)05:08:33

even that is not what I'd expect :)

hiredman05:08:33

Although I guess that is all deftypes, no protocols

hiredman05:08:53

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?

schmee18:08:59

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

schmee19:08:26

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

hiredman19:08:56

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

hiredman19:08:15

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

schmee19:08:09

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? https://youtu.be/r4dNRVWYaZI?t=2100

schmee19:08:10

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