3 ms·
That looks like a really handy feature. I'm assuming you still have macroexpand, macroexpand-1, and a macroexpand-all available? I imagine that you could imple
by emidln 10y ago
That looks like a really handy feature. I'm assuming you still have macroexpand, macroexpand-1, and a macroexpand-all available?
I imagine that you could implement a similar feature for tracing, and if you were careful writing the tracing code, you could then use that code for this feature, as you could say "trace the complication e.g. (trace (eval (read ...)))" and then maybe feed in an optional list of functions to elide . This would be super handy to have as a toggle'able feature, for both macros and normal user code. I use clojure.tools.tracing a lot, and it's a life saver.
- frou_dh 10y agoI don't have a macroexpand function and the self-imposed limit on the number of primitive functions (32 language-related + 16 OS-related) has already been reached! Having a whitelist for macros whose expansion should be traced would be good as there's a lot of noise. "Non-intrusive" tracing of any expression can be done, using an @ prefix, based on this: (extend-parser "@" (mac (x) `(let once ,x (seq (eprintln "TRACE: " once) once)))) e.g. (def third (div 100.0 3.0)) => TRUE (add @(mul third 2.0) third) TRACE: 66.66666666666667 => 100.0 That's a good point that you mention tracing needing to be toggleable - it'd be nice to be able to leave all the @s in code. I guess the macro for "@" could either be conditionally replaced with an effective no-op, or it could internally check for the existence of (or truthiness of) a global tracing-enabled definition.