If you open up the details of BSL and select to enable tracing, and run my example, you do indeed see a stack trace in a panel on the right: (sub2 2) (reciprocal 0)
However, there are clearly some limitations to this tracing mechanism, when my student tried to enable tracing on his big-bang program, running the program caused the whole thing to blow up with the error: syntax-original?: expects a syntax, given '...signature-syntax.rkt:58:42 Is this a bug in the tracing mechanism, or a known limitation? The stepper works great for simple expressions to build understanding of evaluation processes, but for a larger big-bang program, where the underlying model has potentially been changed by multiple tick and handler functions, it offers little assistance for determining what the model is at the time of error, and how it got that way. If tracing is not easily available in BSL, my ideal would be that every error prints out not only the function/line where the error occurred, but also the input(s) to the function which triggered the error. (Example: a function containing a cond, and every branch tests as false, so it reports an error -- but it currently doesn't tell you what the input was which caused all the cases to fall through). Even without a full stacktrace, that would be incredibly useful. It gives you something to reason about, something to build a failing test case which you can then try to fix. Any preferences or settings that can be tweaked to achieve something like this? I showed my student how to build an else case with (error x) to print the value of input x if all the cases fall through, but would prefer a more automatic approach. --Mark On Thu, May 2, 2019 at 4:15 PM John Clements <cleme...@brinckerhoff.org> wrote: > Well, I see two things going on here. > > First, this example is an interesting one, because there’s no stack trace > to display; the (/ 1 n) is the only “frame” left on the “stack”, because > the call to sub2 has already returned, and the body of “reciprocal” is in > tail position with respect to the call. If you add a “(+ 1 …)” around the > reciprocal call, then there’s a stack to display… > > …except that you still won’t see an arrow in BSL, because that’s a #lang > racket thing. That is: if you change the language to “Use language defined > in source”, and insert #lang racket at the beginning, and add a (+ 1 …) > around the reciprocal, and run the program, you’ll see an arrow from the (/ > 1 n) to the (+ 1 …) context as I believe you expected. > > I think the pedagogically correct answer here is that the arrows that you > see in racket aren’t really the “right thing” for an educational setting. > Instead, I think I might suggest using the stepper, instead. (Me? Biased?) > In this case, I think I would jump to the end of the evaluation, and then > step backward to see where the error came from. > > I also think that there’s probably value in the “tree-cer” approach that > Krishnamurthi et al. have been working on[*] for Pyret, which shows the > evaluation of a term as a single large tree, allowing you to inspect each > call and the arguments that were passed to each call. > > John > > [*] I thought of it independently, but they thought of it first, and > actually implemented it. :) > > > > On May 2, 2019, at 4:02 PM, Mark Engelberg <mark.engelb...@gmail.com> > wrote: > > > > Working with a student in DrRacket for the first time in a while. > > > > I notice that in BSL, an error in a function does not tell you what > input to the function caused the error, nor does it show the stack trace by > drawing arrows in the definitions window the way I remember. > > > > When did this behavior change? Is there a way to turn on better error > reporting and stack traces? > > > > Example: > > > > (define (reciprocal n) > > (/ 1 n)) > > > > (define (sub2 n) > > (- n 2)) > > > > (define a (reciprocal (sub2 2))) > > > > > > > > -- > > 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. > > For more options, visit https://groups.google.com/d/optout. > > > > -- 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. For more options, visit https://groups.google.com/d/optout.
