By changing (fact 5) to (* 2 (fact 5)), the stack information becomes /: division by zero errortrace...: /Volumes/ramdisk/fact.rkt:6:17: (/ 1 0) /Volumes/ramdisk/fact.rkt:7:12: (* (loop (sub1 n)) n) /Volumes/ramdisk/fact.rkt:7:12: (* (loop (sub1 n)) n) /Volumes/ramdisk/fact.rkt:7:12: (* (loop (sub1 n)) n) /Volumes/ramdisk/fact.rkt:7:12: (* (loop (sub1 n)) n) /Volumes/ramdisk/fact.rkt:7:12: (* (loop (sub1 n)) n) /Volumes/ramdisk/fact.rkt:9:0: (* 2 (fact 5))
Here, the difference is that (fact 5) is no longer at tail position. I believe errortrace is aiming at preserving proper tail implementation behavior. On Mon, Jul 27, 2020 at 11:39 AM Sorawee Porncharoenwase <sorawee.pw...@gmail.com> wrote: > > (By "integrating" with the new strategy, I meant having two keys: one for the > new strategy and one for the old strategy. I can see that the first entry of > the old strategy is useful, and it's missing in the new strategy). > > On Sun, Jul 26, 2020 at 8:21 PM Sorawee Porncharoenwase > <sorawee.pw...@gmail.com> wrote: >> >> Hi everyone, >> >> I have a question about the implementation of errortrace. >> >> Consider the classic factorial program, except that the base case is buggy: >> >> (define (fact m) >> (let loop ([n m]) >> (cond >> [(zero? n) (/ 1 0)] >> [else (* (loop (sub1 n)) n)]))) >> >> (fact 5) >> >> Running this program with racket -l errortrace -t fact.rkt gives the >> following output: >> >> /: division by zero >> errortrace...: >> /Users/sorawee/playground/fact.rkt:9:17: (/ 1 0) >> /Users/sorawee/playground/fact.rkt:10:12: (* (loop (sub1 n)) n) >> /Users/sorawee/playground/fact.rkt:10:12: (* (loop (sub1 n)) n) >> /Users/sorawee/playground/fact.rkt:10:12: (* (loop (sub1 n)) n) >> /Users/sorawee/playground/fact.rkt:10:12: (* (loop (sub1 n)) n) >> /Users/sorawee/playground/fact.rkt:10:12: (* (loop (sub1 n)) n) >> >> I find this result subpar: it doesn’t indicate which call at the top-level >> leads to the error. You can imagine another implementation of fact that >> errors iff m = 5. Being able to see that (fact 5) at the top-level causes >> the error, as opposed to (fact 3), would be very helpful. >> >> Not only that, (* (loop (sub1 n)) n) also looks weird. There’s nothing wrong >> with multiplication, so I don’t find this information useful. >> >> The tail-recursive factorial is similarly not helpful: >> >> (define (fact m) >> (let loop ([n m] [acc 1]) >> (cond >> [(zero? n) (/ 1 0)] >> [else (loop (sub1 n) (* n acc))]))) >> >> (fact 5) >> >> produces: >> >> /: division by zero >> errortrace...: >> /Users/sorawee/playground/fact.rkt:9:17: (/ 1 0) >> >> ________________________________ >> >> I have been toying with another way to instrument the code. It roughly >> expands to: >> >> (define-syntax-rule (wrap f) >> (call-with-immediate-continuation-mark >> 'errortrace-k >> (λ (k) >> (let ([ff (thunk f)]) >> (if k >> (ff) >> (with-continuation-mark 'errortrace-k 'f >> (ff))))))) >> >> (define (handler ex) >> (continuation-mark-set->list (exn-continuation-marks ex) 'errortrace-k)) >> >> (define (fact m) >> (wrap (let loop ([n m]) >> (wrap (cond >> [(wrap (zero? n)) (wrap (/ 1 0))] >> [else (wrap (* (wrap n) (wrap (loop (wrap (sub1 >> n))))))]))))) >> >> (with-handlers ([exn:fail? handler]) >> (wrap (fact 5))) >> >> which produces: >> >> '((loop (wrap (sub1 n))) >> (loop (wrap (sub1 n))) >> (loop (wrap (sub1 n))) >> (loop (wrap (sub1 n))) >> (loop (wrap (sub1 n))) >> (fact 5)) >> >> This result is more aligned with the traditional stacktrace, and gives >> useful information that I can use to trace to the error location. >> >> It is also safe-for-space: >> >> (define (fact m) >> (wrap (let loop ([n m] [acc 1]) >> (wrap (cond >> [(wrap (zero? n)) (wrap (/ 1 0))] >> [else (wrap (loop (wrap (sub1 n)) (wrap (* n acc))))]))))) >> >> (with-handlers ([exn:fail? handler]) >> (wrap (fact 5))) >> >> produces: >> >> '((fact 5)) >> >> Now, the question: why is the current errortrace implemented in that way? Am >> I missing any downside of this new strategy? Would switching and/or >> integrating with the new strategy be better? >> >> Thanks, >> Sorawee (Oak) > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/CADcuegto9%2BDtFTwAVmiReOcCwpARzBSbFhF0knyexb7UhoHQiA%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAMTzy%2BbkerQnMuNA3%3Do6QHSDy7PZAPPRo6s19G21ECBMKwqHFw%40mail.gmail.com.
