3 ms·

While there are no first-class reader macros in Clojure, reader literals cover many common use cases. For the small set of use cases where you REALLY need read

While there are no first-class reader macros in Clojure, reader literals cover many common use cases. For the small set of use cases where you REALLY need reader macros, it's possible to hack them into the language. One such implementation: https://github.com/klutometis/reader-macros https://github.com/klutometis/reader-macros As far as interactive debugging - that's also something I missed from CL, but is relatively easy to hack into the language. A combination of REPL support for the standard JVM debugger (https://github.com/ohpauleez/cdt https://github.com/ohpauleez/cdt), with a nice expression-based REPL debugger (https://github.com/ohpauleez/cdt/blob/master/src/cdt/debug_repl.clj https://github.com/ohpauleez/cdt/blob/master/src/cdt/debug_r...) gets you pretty far. You can even trigger this environment on any exception using the built-in JVM support (https://gist.github.com/ohpauleez/4ca0b646b89512f38ea2#file-debugrepl-clj-L96-L108 https://gist.github.com/ohpauleez/4ca0b646b89512f38ea2#file-...) To see how far you can take reader literals, hack a look at my talk from last year's Conj, "Unlocking Data-driven Systems" - https://www.youtube.com/watch?v=BNkYYYyfF48 https://www.youtube.com/watch?v=BNkYYYyfF48

armitron 11y ago
Interactive debugging is not "relatively easy to hack into the language". In fact, it's impossible since Clojure lacks the Common Lisp condition system. When an exception is thrown in Java, the stack unwinds meaning all state in stack frames from the point of the throw to the handler gets thrown out. In Common Lisp, the stack does not unwind and high level logic can simply restart the computation (after fixing the error or trying different strategies) without losing any intermediate state. This killer feature is what makes interactive debugging possible. Hacks like the one you linked to are a sorry state of affairs compared to what I described.
- ohpauleez 11y ago
  While I appreciate the dialog, your comment is rather condescending. I've worked extensively in Common Lisp and am well aware how the condition system works. My claims had little to do with conditions, and more about the benefits and use - It's pretty simple to have a dynamic var (say, handler), bound to anything you like, catching errors before the stack unwinds, including an expression-based REPL debugger, allowing you to change locals and return a value in the place of the exception. It has all the limitations you can imagine, but for many cases, this is plenty to be effective.

armitron 11y ago

Interactive debugging is not "relatively easy to hack into the language". In fact, it's impossible since Clojure lacks the Common Lisp condition system. When an exception is thrown in Java, the stack unwinds meaning all state in stack frames from the point of the throw to the handler gets thrown out. In Common Lisp, the stack does not unwind and high level logic can simply restart the computation (after fixing the error or trying different strategies) without losing any intermediate state. This killer feature is what makes interactive debugging possible. Hacks like the one you linked to are a sorry state of affairs compared to what I described.

ohpauleez 11y ago
While I appreciate the dialog, your comment is rather condescending. I've worked extensively in Common Lisp and am well aware how the condition system works. My claims had little to do with conditions, and more about the benefits and use - It's pretty simple to have a dynamic var (say, handler), bound to anything you like, catching errors before the stack unwinds, including an expression-based REPL debugger, allowing you to change locals and return a value in the place of the exception. It has all the limitations you can imagine, but for many cases, this is plenty to be effective.