> On May 3, 2019, at 4:17 AM, Mark Engelberg <mark.engelb...@gmail.com> wrote: > > f 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.
Hi Mark, I think this is a good idea. and we should be able to implement this, but I am not sure yet that we can do it w/o abandoning PITCH (proper implementation of tail-calls, extra H). Perhaps function calls could store their inputs in the continuation marks that John’s stepper places on the stack and a re-defined error could retrieve them from there. Having these arguments, students could then formulate test cases and thus debug their functions. For now, I think adding the ‘else’ case with error is the best idea (of course, not doable if there’ no ‘else’). — Matthias p.s. But please do teach your students the design recipe so that they have a test suite available no matter what. -- 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.
