I'll let other people answer the question regarding what to do, but here's a bit of Guile history:
Guile once had reasonably nice backtraces. At some point the whole old evaluator was replaced as part of the effort to get a compiler and eventually just-in-time compilation to machine code---which is great! It is understandable that the developers involved wouldn't complicate the rather tremendous effort by trying to keep all of the previous, nice, features. They may have thought that something equivalent could be added later. For those historically interested, it seems possible to compile https://ftp.gnu.org/gnu/guile/guile-1.6.8.tar.gz if one adds the following two lines to the top of libguile/__scm.h #include <stddef.h> #include <stdlib.h> To switch on automatic backtraces when entering the interpreter, do the following: (debug-enable 'backtrace) Best regards, Mikael On Tue, Apr 14, 2026 at 10:36 PM Noé Lopez via Developers list for Guile, the GNU extensibility library <[email protected]> wrote: > Hi everyone, > > I got myself in a bit of a rabbit hole tonight, I wanted to figure out > how to have evaluated code give good backtraces. > > So I started digging in (ice-9 eval), and I saw no debug information > coming from `memoize-expression'. > > So I started digging in memoize.c, and I saw no debug information, and I > didn’t understand too much, and gdb was having a hard time with the > structs. > > So I started digging the git log, and I saw this: > > Andy Wingo, 2009 b7742c6b7132544b9d6cd9cb32c09e2084ad9e52 > * libguile/memoize.c: New memoizer, which runs before evaluation, > checking all syntax before evaluation begins. Significantly, no > debugging information is left for lexical variables, which is not so > great for interactive debugging; perhaps we should change this to have > a var list in the future as per the classic interpreters. But it's > quite fast, and the resulting code is quite good. Also note that it > doesn't produce ilocs, memoized code is a smob whose type is in the > first word of the smob itself. > > The same commit mentions that it was made as part of the C-based > evaluator that was supposed to be only used for bootstrapping, but it > turns out that our scheme-based evaluator uses the same memoization. > > So, what to do? I wasn’t there when it happened, and I’m probably > missing a lot of historical information. What was the plan? > > Should it be that a new memoization is made in scheme to go with the > scheme evaluator, or that the existing memoization is adapted to keep > debug information? > > Or am I completely off the mark? > > Thanks, > Noé >
