Question: any idea what went wrong, or how to debug this thing? also lein repl is working fine I already removed ~/.m2 and ~/.lein and fetched all dependencies with leiningen again, to no avail

Asked By
david479
Asked At
2018-01-23 19:09:49

Found 15 possible answers.

User Answered At Possible Answer
mfikes 2018-01-23 19:10:48 @martinklepsch If you were looking for a loop / recur based version of flatten for performance, I bet a fast (directly reducible) one could be written by taking the implementation of flatten and re-writing it with transducers (using (into [] ...) and having it call the tree-seq' here https://gist.github.com/mfikes/cc1d1fac47e7dc112b0b9f4e3de11eae
noisesmith 2018-01-23 19:10:48 @david479 those things should never help btw
mfikes 2018-01-23 19:11:23 At the bottom is iterate , which is directly reducible
noisesmith 2018-01-23 19:11:24 @mfikes but you get the same problem my version with sequential? got - which is that flatten ignores hash-maps
mfikes 2018-01-23 19:11:37 Ahh, missed that nuance
noisesmith 2018-01-23 19:11:48 (that's easy to fix with a custom impl of course)
martinklepsch 2018-01-23 19:12:05 @mfikes thanks, perf doesn’t really matter, it’s pretty small data. Just thought I should be using recursion — and my intuition with regards to recursion is pretty crap :smile: but tree-seq is nice, I like it :slightly_smiling_face:
noisesmith 2018-01-23 19:12:39 a good rule of thumb is that branching can't be optimized recursion without an extra storage arg representing unvisited branches so it's an eager tree-seq thanks to eduction, right? @mfikes oh that version of tree-seq is cool now that I look at it but the lambda continuation thing means it's not a perf optimization, just a stack usage one (in that sense tree-seq is actually doing the optimized recursion, but taking the recursive calls out of the call stack and putting them into continuations in lambdas in the heap) and lazy operations can move your storage out of the stack and into the heap / gc without awkward loop variables for some problems using that is worth it, sometimes the added complexity means it's better for code clarity sake to just use regular recursion
mfikes 2018-01-23 19:17:37 @noisesmith It was actually the basis for a directly-reducible tree-seq that I was planning on contributing to ClojureScript, but it turns out that, since the fns passed to tree-seq are not guaranteed to be side-effect free, this is a no-go Otherwise, if you have side-effect free fns, it can be faster
noisesmith 2018-01-23 19:18:14 very cool or does the consumer decide with eduction? it's eager rather than lazy, right?
mfikes 2018-01-23 19:19:15 Well, it is no more eager than iterate ... but the key was that it be directly reducible
noisesmith 2018-01-23 19:19:27 oh, OK
mfikes 2018-01-23 19:19:44 The actual implementation I was going to contribute didn't use eduction , but was a deftype : https://dev.clojure.org/jira/browse/CLJS-2464 But, I think it is probably the case that it shares a lot of characteristics with iterate
noisesmith 2018-01-23 19:21:52 wow, I can think of so many places where I could have used (eduction (take-while some) ...) ...
mfikes 2018-01-23 19:21:56 It's unfortunate we can't pursue it (it can be up to an order of magnutude faster :slightly_smiling_face: )

Related Questions