wg@opal.cs.tu-berlin.de (Wolfgang Grieskamp) (07/28/90)
JAShley@silver.ucs.indiana.edu (J. Michael Ashley) writes: >What's a suspended call chain backtrace? Maybe a better notion would be "suspension history" ... The problem is to valificate (some more honest word for debugging) programs written in lazy languages. During the valification phase you are looking for errors which should *never* appear in the final version of the program - programming errors. The worst case for such errors is that they dont appear at all for the test input. Slightly better, if the program output dont matches the specification. Best on my opinion if the erroneous program is undefined, ie. its semantical function maps to bottom. This will be naturally the case for more inputs in strict languages then in non-strict languages. To make the program explicitly more undefined, you can use a function like BOTTOM (which may be operational defined as letrec BOTTOM = BOTTOM) whose *semantical* function maps to semantical bottom (i use capitals to differ from semantical bottom). If the evaluation of BOTTOM is ever forced, the runtime system has 2 choices (a) loop forever (b) stop program execution with appropriate error diagnostics. Regarding to the error diagnostics produced when BOTTOM or other expressions which map runtime-detectable to semantic bottom are evaluated comes the "suspension history" in play. In a strict language the history which leads to bottom is (in general) available through the control stack. In a non-strict language you have at least two historys of interest: that which leads to the construction of a suspended undefined expression, and that which leads to evaluate the undefined expression. In fact you have n historys, because the expression which leads to evaluate a suspended undefined expression maybe itself suspended, and so on. This is what makes debugging in non-strict environments so hard. A little help could be, that suspension of expressions like BOTTOM is compiled specific, in that the history which leads to suspension is memorized. But even if the history is memorized for all suspensions (which would be very expansive, but in debugging mode, why not?) its very hard to put all those historys together to a meaningful picture in larger program systems. This is related to the problem of debugging in parallel environments, but you have it inherently and with very fine granularity in the pure non-strict paradigma. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Wolfgang Grieskamp wg@opal.cs.tu-berlin.de tub!tubopal!wg wg%opal@DB0TUI11.BITNET