Re: Guile debugger workgroup?

[Ludovic Courtès]

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> I also agree!  It's hard to convince people to pick Guile for their
> project when there is:
>
> 1. Lack of a debugger that can break and step anywhere in your source
> code
> 2. Lack of debugger integration to an IDE (it's not even integrated into
> Emacs)

Well, Guile has a debugger that lets you do that (modulo inlining etc.,
as with any other compiler), and Geiser is not Visual Studio™ but it
does a good job.

Also, I think I mentioned before that I almost never use breakpoints on
Guile code—not because of some deficiency of the debugger, not (just)
because I’m silly or inexperienced, but because it’s rarely the right
tool for the job.

I believe this is largely due to (1) writing functional code, and (2)
doing live programming at the REPL.  Why would you use breakpoints when
you can just call the relevant procedures on some input to see how they
behave?

So I think you won’t convince people to pick Guile for their project by
selling it as a C/C++/Python drop-in replacement.  Guile is about
functional programming and live coding so the set of tools differs.

> Perhaps we should assemble a Guile debugger workgroup that'd review
> what's broken, what's missing, what can be borrowed from other Scheme or
> languages for inspiration, and hopefully improve the Guile debugging
> experience? :-)

Despite what I wrote, I think it’s a good idea.  I suppose inspiration
would come from other Schemes, in particular Racket, and perhaps from
other live-coding systems (Common Lisp, Smalltalk, etc.), rather than
from Python or C.

Ludo’.