lazy sequences can (to some degree) be built from transducers - see sequence . The one caveat is that intermediate expanding results are not themselves fully lazy, so we try to call those "incrementally computed" rather than "lazy".

Also, according to the OP, Rich Hickey has since received knighthood

Maybe I should have said, "transducers would be more central than the seq API"

An ideal was for a Lisp to run as briskly as the OO, as if "on the metal". Transducers produce less garbage.

Notably absent from even the Reddit comments is that there be a language specification or any difference in social structure. There is a comment about the ns form... which IIRC was a community contribution... 2008 was a relatively stable era. Java had calcified into bedrock. MIT taught Scheme. I wonder whether the greater fragmentation (Rust, Dart, Swift) and faster churn of 2024 might be less conducive. In the age of swiftly-starting cloud containers, I wonder whether a Clojure-in-2024 would involve the JVM at all, or more as a peer-among-equals. I wonder whether a Clojure in 2024 would provide async-only I/O periphery for better portability among JavaScript and Dart. I wonder whether the founding ethos would be the same.

I doubt there would be a language spec, even if Clojure was being created as a fresh language today. Most individual language designers just don't go that route... ...and I still think it would be very solidly a "hosted language" as that's part of what gives it the power and reach it has: leveraging all the optimizations of the host runtime and the huge ecosystem of existing libraries. Leveraging host async features more? Yeah, probably I think.

I would imagine a protocol-based core that would be completely host-language agnostic?

"I wonder whether the greater fragmentation (Rust, Dart, Swift) and faster churn of 2024 might be less conducive." Or more conducive. A nice win of Clojure is that it is simple enough to be reasonably ported to new hosts, keeping thus all the Clojure goodness. First Java, then JS, then GraalVM, now Dart...

Transducers by default is a big one for me. 90% of the new code that I write is transducer-based only; Only use lazy sequences if an underlying library/abstraction requires it.

Protocols for core fns sounds good in theory but I am weary that if it was to be realized (ofc very unlikely at this point) it can open a can of worms where overloading of core fns by the community could result in hard to reason about semantics (i.e. overload core/+ to merge sets or some such…); not sure if that can be restricted in any meaningful way or made less confusing – sounds like something that could work well in a statically typed language where one would always more or less “know” what’s the data/object they are handling (this is of all pure improvised speculation on my part).

Solution found for Calva tools in VS-code see https://clojurians.slack.com/archives/CBE668G4R/p1712828427037589?thread_ts=1712824073.960319&cid=CBE668G4R

No REPL involved but I have used Telepresence in the past. Worked great from 2.10.4+, didn't "work on my machine" before that version. They're well past that now. My 2 cents.

No. Even if it were possible, it would only serve as documentation because of type erasure.

Yeah, I wasn't having the problem I thought I was having 😄

is it? I treat it as a global thing, it's a var used in compilation phase.

I mean, when I use it in one namespace, it does not affect others. Context: I'm a lib developer, and I'm arguing with my team that there is no issues on leave (set! *warn-on-reflection* true) in our lib.

when your lib is on the path and namespace with (set! *warn-on-reflection* true) is evaluated all further compilations will be affected. User may get a bunch of warnings about reflection from other libraries (these which do not care about reflection)

good example is lein check which sets this warning and then loads each namespace to force compilation. It's common to see plenty of warnings from libraries you depend on.

That's not correct. lein check is not a good example because it does additional things under the hood. Plain set! establishes a local thread binding, it's overwritten by any subsequent call to popThreadBindings. Loading a namespace (or a file) first pushes the bindings for some vars, then pops them after all is done. Those vars include *warn-on-reflection*. So any set! will only have its effect within that namespace/file. That's easy to confirm:

$ clj -Sdeps '{:paths ["."]}'
Clojure 1.11.2
user=> *warn-on-reflection*
false
user=> (spit "test.clj" "(set! *warn-on-reflection* true) (println 'inside *warn-on-reflection*)")
nil
user=> (load "test")
inside true
nil
user=> *warn-on-reflection*
false

What can be used to alter the var globally is alter-var-root. Another way is to use set! before any particular thread binding might occur - e.g. with clj -M -e '(set! *warn-on-reflection* true)' -r or before calling load (which you shouldn't really use anyway). There's also the clojure.compile.warn-on-reflection property, but it's read only by clojure.lang.Compile/main and I don't know where it's used. Maybe to compile Clojure itself?..

Ok, thanks for clarification. So my understanding was wrong...

Anyway, there was a discussion about not including this in the published libraries. I don't remember a motivation now tbh...

I know that it is OK to include this on libs. I just want a documentation reference to include in my argument. Clojure itself do that in some namespaces like clojure.instant I understood the @U2FRKM4TW explanation, but it is a little bit too technical. I think that will be useful if we have an explicit explanation/docs about it in http://clojure.org, or at least, a good docstring.

> Documentation reference > Does https://clojuredocs.org/clojure.core/*warn-on-reflection* address your need?

> When set to true, the compiler will emit warnings when reflection is > needed to resolve Java method calls or field accesses. > Defaults to false. Yeah, the compiler will emit warn to all namespaces? only this one?! the ones "after" this one? it is not clear.

Here is the discussion about including (or not) warn-on-reflection settings: https://github.com/clojure-emacs/refactor-nrepl/issues/347#issuecomment-907795057

Also it causes a fail of clj-refactor for example

I’d personally really appreciate an example on Clojuredocs that covers this … set of problems, knowledge and known approaches. (I don’t feel like I understand the problem completely myself)

There are no issues to leave this setting in a namespace. We do this in core namespaces that do Java interop as a common practice. There is no perf impact if you have no reflection.

Putting it before the ns call would check this in any transitive namespaces, which you may not want so usually you should put it after the ns call

@U064X3EF3 Could we have something like "when placed after the ns call, will only affect the current namespace" in the docstring, or somewhere else in clojure docs?

Feel free to file a clojure-site issue for the docs or ask clojure for the docstring

@U1EP3BZ3Q I just read through that thread on GitHub. I haven't delved into the impl details, but it seems more likely to be an issue with how that particular project loads files - not with a top-level (set! *warn-on-reflection* ...) itself.

> What can be used to alter the var globally is alter-var-root This will not work either unless you do it with the clj -e "..." thing, since when the repl starts it already adds a thread binding with false, so even if you set the root to true, the var inside the repl loop has the false shadowing the root

Hmm. Maybe it only works in user? Not sure, but it was definitely working back when I was using it in that ns.

interesting that the clojure main repl https://github.com/clojure/clojure/blob/master/src/clj/clojure/main.clj#L82-L99 initialize *compile-path* from clojure.compile.path jvm property but doesn't initialize *warn-on-reflection* from clojure.compile.warn-on-reflection property

https://ask.clojure.org/index.php/3787/theres-enable-warn-reflection-from-command-running-clojure?show=3787#q3787 is a thing you can vote for in this area

we are probably going to look at something in this area for next release

but I think for a global warn-on-reflection to be useful you would also need a way of constraining it to certain namespaces, because it will complain for all your libraries also, which you probably don't wont in some situations

and you probably do want in some situations :)

yeah exactly

> Maybe it only works in user yeah, adding that to a user.clj file seams to work because it will load before clojure.main