Clojurians Log v2

I know I’m late to the party, but I was looking at @sickill’s take 2. It’s “nicer” in that it’s based on data structures and lazy seqs, rather than process. But I’m always uncomfortable with using “last"

quoll: hey :simple_smile:

unfortunately, my best approach would use loop/recur

hi

yeah, my (unpublished) take 3 was with loop/recur actually

:simple_smile:

and I'm still torn between these 3

loop/recur seemed nice to me because it lets you check the upcoming (the second) delay/frame pair, and if they had gone over, then return the first one

and you only go over the frames once (“last” makes you iterate through them a second time)

true

The “loop” form let me unpack heavily. Not sure if that’s good style or not :simple_smile:

I didn't think of it this way (that last makes it iterate again)

yeah, I'm not sure either, that's why I asked here 😉

:simple_smile:

My loop form was: (loop [[current-delay-frame & [[next-delay next-frame] :as r]] frames t 0] …)

which is a convoluted unpacking of “frames” :simple_smile:

reduce/reduced is becoming more common.

current-frame-delay being the first pair, and next-delay/`next-frame` being the second, with r holding from the second onward. So it’s actually a lot of work hidden in the expression

reduce is certainly higher level than loop.

I used to rely on loop/recur a lot but people have often pointed out to me that loop/recur is kind of a last resort sort of thing.

I’m embarrassed to admit that I was not aware of reductions :simple_smile:

@quoll: Don’t be embarrassed. There are so many hidden gems in Clojure. Stuff like ffirst and whatnot are just right there but sometimes unseen.

I prefer not to use loop/recur. OTOH, there is value in it if it lets you define a function more clearly

I resorted to it this time because it let me avoid the backtracking

everything I could see that worked on sequences would put me 1 step too far down the seq. @sickill managed it by keeping the head of the discarded seq, and then iterated to the end of it with last

Ah! I know a technique for dealing with that! Doh!

it need not be done with this syntax, but work on a structure like: (map vector (rest frames) frames)

ie. pair up every frame with it’s predecessor

frames are already 2-element vector pairs, so it’s getting messy by this point :simple_smile: (it’s vectors all the way down!)

quoll: this pairing (frame with it's predecessor), you would use that with loop/recur or reduce?

recur is used throughout the whole SICP, you could say the whole book "stands on it", so I guess that's the classic lisp approach

but not all problems look clean/readable when done with loop/recur imho

reduce/reduced does the job and it's quick, but it has this imperative break feeling

sorry, was away

no, with pairing you can use drop-while with the test on the first element (which is shifted 1 back, via rest), and then the result will be at the head of the remainder, on the second element

ah, right

I’ll confess that it doesn’t work all that cleanly. The boundary conditions aren’t handled as well