Debugging dynamic rules is more complex than it should be. People just want to see the actual rules they have define: the complete lhs and the complete rhs with possibly more bindings. This needs some support in the compiler, since this cannot be implemented as a library. Showing the complete stack of a given dynamic rule would be most useful.

Submitted on 2 March 2006 at 23:15

STR-530, visser:
That would indeed be useful. However, in general it is not possible. A dynamic rule, is well, dynamic. The hashtable mapping for a dynamic rule only reflects only part of the information. In the case where the lhs of the rule and the rhs are completely bound at rule definition time, and the condition of the rule does not have any side effects (think SpecializeCall in the partial evaluator), then it is possible to create a vanilla picture of the stack of dynamic rules. In general, it is necessary to apply the dynamic rule to determine the rhs of the rule. In the case that the lhs contains application-time bindings (again consider SpecializeCall or UnfoldCall) it is not clear what the rule should be applied to. In addition when the rule has side-effects, (for example, generating specializations), then debugging the rule would have the effect of performing the side-effects.

But in the special (but common) case of simple dynamic rules such as in the case of constant propagation, it would be possible and useful to provide this kind of support. Hower, it may lead to expectations that cannot be satisfied for more complex uses of dynamic rules.

STR-530, martin:
It would be nice if for more complex examples the source of the dynamic rule is shown, where the context variables are replaced by their actual bindings.

This general should also work for simple dynamic rules …