clojure 2026-06-28

maybe to illustrate a little more... when we mess around with lists or maps, we use the immutable and persistent structures and enjoy the fact that we can pass them on to other functions or threads and know that our value, at our finger tips, will not break, will not get corrupted, will not change. it makes it simple to reason about. at least on a read-only file handle, a similar experience would be rather nice, no?

although line-seq itself does not do any I/O

anything that can be split into units can be turned into a reducible that can also clean itself up at the end, and be processed via reduce + transducers, e.g. edn forms, but that always requires working on top of the Java APIs Though it's not idiomatic in the sense of a common pattern.

when we mess around with lists or maps, we use the immutable and persistent structures and enjoy the fact that we can pass them on to other functions or threads and know that our value, at our finger tips, will not break, will not get corrupted, will not change
How can you possibly ensure the same things when IO demands mutability? Even with read-only files - they are read-only only within the logic of your app. Nothing in your app can prevent thirdparty changes to those files, renames, moves, partition unavailability, network issues, etc. So unless I completely misunderstood the point, it seems like you are trying to create a neat high-level abstraction over something that demands a lower-level approach. Even NFS, which is extremely lower level than what you're describing, is quite terrible. ls on top of something served via NFS can hang your system. Just because network-specific things were ignored for the sake of a neat FS abstraction.