Clojurians Log v2

I think you are correct. Challenge: given this "bug", can you come up with a code snippet where this causes a false positive?

not yet lol

i suspect that :seq is already being used as :nilable/seq, where things that expect a seq intelligently deal with nils

the thing i'm thinking about is that :seq is overly broad, so you can't say "this function takes a non-empty sequence"

it's permissive so there's no issues right now, but i'd like to be able to say "this function errors if given an empty sequence" and then calling (foo (seq coll)) would say "hey, this might be mismatched"

encoding non-emptiness in types isn't trivial right?

sorry, yes

wrong example

i mean the difference between (rest foo) and (next foo)

where (rest foo) will always return a truthy value, and (next foo) will return a truthy value or nil

but both of them are typed as returning :seq

(if (rest ()) :true :false)
; :true

ah yes, I was just typing:

(if (rest '()) :a :b)

lol

this should warn about always being truthy

rest can return nil

(if (rest nil) :a :b)
; :a

i'm interested to see rest return nil, i'm not sure how to do it

oh, do you have to write a custom deftype that returns nil in the more impl?

Sure, its a java method call that returns a reference type

can map or filter ever return nil?

The current impl won't

They try to be maximally lazily, and which dictates immediately returning some kind of delayed value, so not nil

But I think they certainly could be changed to return nil immediately without breaking the maximal laziness, just slightly more awkward code

well, for the purposes of clj-kondo, i think assuming rest and map and other core functions return truthy objects and seq returns a nilable object is worthwhile

> Not sure what you are trying to say, (lazy-seq (rest s)) in the above absolutely keeps a reference to s until it is realized I meant that in (defn foo [s] (lazy-seq (foo (rest s)))) it seems like a good idea for rest to be an eager operation so recursive calls don't hold the head of the seq.

I always find it satisfying when something is fixed with tangible benefits. E.g. I now fixed an issue in SCI that I had in the backlog for two years and now I finally ran into a situation where it was worth fixing the issue. Perhaps I could have fixed it two years ago but at least I now have more understanding of why the fix is necessary... Something similar is going on here. I've never found an issue with the :seq type for things that expect nil or a seq... perhaps it's there though!

i'll play around with it, see if this makes any difference

IMO rest returning nil violates documented behavior. and I think it can be argued that the rest abstraction is at least as eager as seq and just returning a delayed value without dropping the head of the collection is not the intended implementation. consider this

(defn foo [s] (<...> (lazy-seq (foo (rest s)))))

I have a mildly convincing draft blog post somewhere. But this is my summary from my pov, from https://frenchy64.github.io/fully-satisfies/latest/io.github.frenchy64.fully-satisfies.head-releasing.html that improves the memory usage of core functions: > At the very least, this work helps crystallize the differences between rest and next---or more precisely, their similarities: while rest does not realize the next element, nor tell us whether a seq has more elements, it is still an eager operation whose result, like next, releases a strong reference to the first element of the seq.

I think in terms of least to most eager it's seq < rest < next. Though honestly I don't think I've really nailed the argument, so I've mostly just kept it to myself. Interesting stuff tho. I suspect rest < next since next is described as (comp seq rest) in places, so I think next must realize 2 elems, but rest only 1. But maybe seq <= rest?

Not sure what you are trying to say, (lazy-seq (rest s)) in the above absolutely keeps a reference to s until it is realized

In general this is why you don't see lazy seq ops in core defined in a way that do stuff before being wrapped by the lazy-seq macro

make consumers force the seq to get anything, and once the seq is forced the result can be cached any references that where held to compute that step.can be cleared