Re: Guile debugger workgroup?

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> 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.

I'll try to get more concrete with actual scenarios, but for now it's
just a feeling that "it rarely works", e.g. break points don't stop or
the code stepped is hardly recognizable.  Perhaps Guile aggressively
inline things or macros add to the confusion, but that shouldn't be a
price the user has to pay for.  One of Guile's strong points is supposed
to be that it's geared for interactive programming, and I'd categorize
stepping code being related to the programming experience being
"interactive".

> 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?

And I've probably countered that before by saying that while it's true
that functional programming helps, there are still times where the
inputs or the lexical environment I need to understand are complex
enough that reproducing them at the global level (REPL) is a pain.  Just
breaking at the right place and typing ,locals would be a much more
efficient way to proceed to see what the environment in scope looks
like.

> 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.

Debugging/live coding abilities do not have to be mutually exclusive.
Python excels at both, in my experience.

>> 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.

Great!

-- 
Thanks,
Maxim