Clojurians Log v2

@cfleming https://github.com/imrekoszo/unlazy/releases/tag/v1.1.0

@imre Release with 2026.1 EAP support out now!

Shortly! Sorry for the delay with this.

No worries. So far I haven't seen anything that makes me want to rush upgrading 🙂 Since Jetbrains stopped publishing those nice EAP release pages I kinda lost interest. I'm not going to parse pages or release notes...

Yeah, I'm not even sure where they announce the new EAP series these days, they used to write a blog post but no longer do.

I was always looking forward to those posts

BTW I just found https://github.com/imrekoszo/unlazy, which was just what I was looking for.

Thanks!

nice! what are you looking to use it for?

I'd like to write this as an inspection in Cursive with quick fixes to translate to the transducer equivalents.

But right now I'd just like to get warned when I use those forms.

Sometimes the rewrite isn't trivial 😛

You don't have for on the list there, any reason why?

Oh I'm sure.

That's actually something I was wondering a few weeks ago

Sometimes it's easier if you have cgrand's xforms around.

x/for should be a good replacement but it must be noted that it produces an eduction and so it isn't cached

gotta love xforms

PRs are welcome to unlazy

both on "what to warn on" and "what alternatives to suggest" line

Yes, I'm not sure how the inspection could adequately warn the user when the semantics aren't identical. Often I don't care, and I actually want a vector instead of a seq, even though the semantics are different.

Maybe something like "Convert (map foo x) to (into [] (map foo) x) (semantic change)"?

Not sure how long those descriptions can be, might have to be "Convert lazy map to use into [] (semantic change)?"

Then there could be a couple of different options to convert to into []', sequence` etc, and just warn on those which are semantic changes.

It depends on usage really. If the entire result is then consumed somehow then it's good. But if it's further processed with another sequence op, then transducer composition might be better. Or a transducible context that produces the wanted result, like a string rendering of the vector.

Yes, I'm sure there's approximately infinity refactorings in there somewhere 🙂

I only added vague suggestions to tgis collection of linter rules because of this.

I'm not sure what a good ux would be here. Low hanging fruit quick fixes is nice for simpler cases and devs newer to the concept. But they might make it easier to miss a more impactful refactor, which could be too complex to suggest in a quick fix.

Warning is nice as a start

Yes, I wonder if it would be possible to factor the refactorings into simple atomic operations, so first you could convert ->> to some form, and then have additional operations to factor out the transducible context from the resulting comp.

{:file   *source-path*
 :line   (.getLineNumber *in*)
 :column (.getColumnNumber *in*)
 :e      (main/root-cause e)}

Printing file://<absolute-path>:<line>:<column> got me there

Sounds good, I'm not sure there's a better solution if you can't control the eval.