Guile debugger workgroup? (was: Coding style: similarly-named variables)

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

Hi Simon,

zimoun <zimon.toutoune@gmail.com> writes:

> Hi Maxim,
>
> On Mon, 21 Nov 2022 at 15:55, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
>
>> In practice since using breakpoints/a debugger to debug Guile code
>> rarely works as intended (in my experience hacking on Guix!), we
>> typically sprinkle the source with 'pk', and that point becomes moot.
>
> I totally agree!  Preparing some materials for introducing Guile to
> GuixHPC folk, I am trying to collect some tips and, if I am honest, the
> debugging experience with Guile is really poor; compared to others (as
> Python).  For example, DrRacket provides an easy and nice user
> experience [1] – where it is easy to compare each intermediary result in
> the debugger.  For what it is worth, I have not been able to have some
> similar inspections as in [1].  Maybe, I am missing something…
>
> Well, IMHO, we are somehow suffering from some Guile limitations and
> improvements in this area are an hard task.

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)

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

-- 
Thanks,
Maxim