There has been talk, usually on April 1st, of augmenting standard computer language instructions like "goto" with ones such as "comefrom".
More seriously, I've noticed that debugging often consists of tracing backwards through a program from the point at which an incorrect result appears to get back to the point of the error. This is where good modularization - especially avoidance of globals - and the ability to cut back the calling stack greatly helps this kind of detective work. It would be handy to be able to run backwards while displaying selected values to automate some of these manual debugging steps. The problem of automatically computing the inverse program seems potentially unsolvable in the general sense. On Mon, Feb 21, 2011 at 1:16 AM, Steven Taylor <[email protected]> wrote: > Hi, > > Just sharing a thought. > > I was flicking through this old text book "The Science Of Programming" by > David Gries (1981), while thinking that it was one of the few I remembered > -- it made an impression on me. > > Here's a quote: "Wouldn't it be nice to be able to run a program backwards > or, better yet, to derive from one program P a second program P-1 that > computes the inverse of P? That means that running followed by P-1 would be > the same as not running any program at all! Also, if we had the result of > executing P, but had lost the input, we could execute P-1 to determine that > input. " > > -Steven > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > -- Devon McCormick, CFA ^me^ at acm. org is my preferred e-mail ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
