imagine the API didn't exist
what would you do?
what I do today
I don't know that I use it ever
but that doesn't mean it is good ergonomics to be like "type code into your repl and it just runs forever even if you made a mistake"
that's not what I said
let it run in the background, and return input control
no one wants that
it's worse to give the people the illusion that they can stop bad loops 100% of the time without hitting the things that the Thread.stop() warns about
the next question in #beginners is going to be "why is clojure eating my cpu, ram, and filesystem?"
Isn’t it better to let them try and if it doesn’t work they can kill the process just as if they didn’t have the tool?
I am not saying Thread.stop is good, I am saying basically everything you would reason about by analogy (setting aside if the analogy is good, os processes, ec2 instances, etc) has some kind of kill switch and that is a very useful usability affordance of those systems, and it is unfortunate that we, as part of the jvm community, are unable to offer a useful feature
It seems that interactive Clojure dev systems have a reasonably common use of Thread.stop today, from recent discussion here. I can see why -- it is expedient, and despite the warnings, often does "what you want", in a sharp-knife-that-sometimes-cuts-you kind of way. If Thread.stop is removed from a future JVM completely, it does seem that having a different approach in common use would be useful. I doubt many people want a Clojure compiler that forces interrupt status checks into all loops, though.
our mystery seems to be resolved, but i tried using test.chuck anyway -- imagination expander :) thanks for pointing it out -- i think i may have other uses for it!
The alternative for a lot of cases to Thread.stop() is basically kill your REPL process and start again.
If that’s not good, then I think at least offering Thread.stop() as an option is ok - it’s (AFAICT) always worked for me, and saved me many REPL restarts. If my app does get funky after using it, I’m still going to be restarting my process anyway.
For anyone following along, who like me was clueless about Thread.stop(), I found this: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html (linked from the Thread.stop() API docs)
in sci I have something called :realize-max
which sets a hard limit on the length of sequences being realized. of course this comes with significant overhead, but for sandboxing things like 4clojure puzzles I guess it's fine.
user=> (sci/eval-string "(range)" {:realize-max 10})
Error printing return value (ExceptionInfo) at sci.impl.max-or-throw/bottom$fn (max_or_throw.cljc:8).
Maximum number of elements realized: 10
(0 1 2 3 4 5 6 7 8 user=>