Re: How to best add logging/debugging code?
On Thu, Nov 27, 2003 at 02:19:53PM +0000, Malcolm Wallace wrote:
Apart from changing the evaluation order of expressions, trace has other drawbacks, noted I think by Lennart(?) but I can't remember exactly where. One issue is this:
Consider an expression where the printable argument to 'trace' causes the evaluation of another expression which itself is defined using 'trace'. The nested 'trace' outputs will appear interspersed with each other. In recursive definitions this can become quite painful to disentangle.
Perhaps trace should be redefined: trace msg v = foldr seq (old_trace msg v) msg
Ross Paterson
On Thu, Nov 27, 2003 at 02:19:53PM +0000, Malcolm Wallace wrote:
Consider an expression where the printable argument to 'trace' causes the evaluation of another expression which itself is defined using 'trace'. The nested 'trace' outputs will appear interspersed with each other. In recursive definitions this can become quite painful to disentangle.
Perhaps trace should be redefined:
trace msg v = foldr seq (old_trace msg v) msg
Hmm. This suggestion has the potential to confuse the casual user even more. Consider debug s x = trace (s++": "++show x++"\n") x f x = debug ("entered f") (... g y ...) g y = debug ("entered g") (...) main = ... f ... With the current definition of 'trace', although the formatting is ugly, the user (correctly) sees that the evaluation of f is entered before g. entered f: entered g: val_g_y val_f_x With your suggestion, it would appear that g was entered before f. entered g: val_g_y entered f: val_f_x As I recall, hbc had a partial solution to the interspersal problem by annotating every 'trace' output with a nesting level, e.g. trace(0): entered f: trace(1): entered g: val_g_y trace(0): val_f_x However, none of these behaviours is ultimately satisfactory. Regards, Malcolm
participants (2)
-
Malcolm Wallace -
Ross Paterson