Hey Lee. I'm learning conditional restarts myself…. thus the reason why I implemented the library so I'm probably not the best person to ask
As far as I know… restarts have to be supported by the language itself in order for it to truly blossom the way you are describing it. ribol is just a library, not a platform and definitely not a development environment. I'm not sure what the state is with https://github.com/pallet/ritz but I think that it may be what you are looking for in a development environment. Chris. On 27/09/2013, at 11:06 AM, Lee Spector <lspec...@hampshire.edu> wrote: > > I apologize for the naivety of this question, but whenever I see > libraries/discussions of enhanced mechanisms for > exceptions/conditions/errors/restarts/etc in Clojure I wonder if they could > provide a couple of features that I dearly miss from Common Lisp, and this > contribution makes me wonder the same thing. I looked briefly through the > guide (nice diagrams!) but couldn't quite tell if it could do what I miss > from Common Lisp in Clojure, and therefore whether I should take the time to > study it in more detail. > > What do I miss from Common Lisp condition handling? > > When you hit an error in Common Lisp you get a REPL (sometimes called a > "break loop") that lives in the context where the error occurred. The most > useful thing to me is that you can examine the state of the system there > (through normal REPL interactions) and look at the values of local variables > all up and down the stack. In addition, you can change the values of > variables and restart the computation, and the restart mechanisms can be > customized based on the type of error/condition... which is very cool and > occasionally useful, but for me personally the big win is in just being able > to really examine the state at the point of the error (including running > little pieces of code to help to examine the state, etc.). > > Note that this happens in Common Lisp wherever an error occurs, and the > programmer doesn't have to mark or wrap expressions in any special way to get > this functionality. Which is crucial, because many of the situations in which > this is useful are ones when you hit an error that you had no idea existed, > and you certainly didn't know in advance where errors would occur. > > Another Common Lisp feature that's very handy in this context is the ability > to trigger an interrupt manually from the keyboard and end up in the same > kind of break loop. Your program seems to be hung and you have no idea what > it's doing? Interrupt it and look at the stack and the local variables. > Everything looks okay but it's just taking a long time? Restart and you're > back in action, continuing from where the interrupt occurred. If it doesn't > look okay then examine the state to try to figure out what went wrong, abort > the computation, fix the problem and re-run from the beginning. > > My sense has been that this kind of functionality doesn't exist in any > Clojure environment, maybe due to something about how the JVM works (about > which I don't know very much, which may be very clear to all of you :-). But > when I see fancy new conditional restart mechanisms etc. then I get a glimmer > of hope that maybe I'm wrong about this. > > So, can any existing libraries/systems in the Clojure ecosystem provide this > functionality? Is it conceivable that any would in the future? > > Thanks, > > -Lee > > > > > On Sep 25, 2013, at 3:14 AM, zcaudate wrote: > >> I've done a pretty comprehensive guide on conditional restart systems in >> clojure with diagrams to show why it is much more flexible over try/catch >> mechanism >> >> Project: >> https://github.com/zcaudate/ribol >> >> Generated Documentation: >> http://z.caudate.me/ribol/ >> > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to a topic in the Google > Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/elRWA13Iidg/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
