Re: [Chicken-users] Debuggery

[felix]

Category 5 wrote:
> I think debuggability is a *MAJOR* factor in the wider adoption of
> Scheme for real-world programming.  This is one area where Common Lisp
> completely destroys Scheme right now.

This is quite correct.

> On debugging:
>
>   - debug.scm is a huge win and solves a big chunk of the problem.
>     Thanks very much for this!  Can you post it somewhere on the web?
>     Actually I think it should be part of the core distribution.

I'll fix a couple things and put it to

http://www.call-with-current-continuation.org/debug.scm

in a few minutes.

>   - Would it be feasible to allow the gensyms (g1415, etc.) to be
>     referenced from within the debugger?  i.e. they can be seen in the
>     environment but one can't, for example, return the value of one from
>     a call frame.

Ok. Added.

>   - It might be nice to have a debugger state that just prints a
>     backtrace on error without dropping into the interactive debugger.
>     Another possibility would be to make a (backtrace) or ,b command
>     available in the base interpreter that could be invoked at will (a
>     la Guile).

You can now enter (debug #t) to enable the debugger (otherwise it will not
enter the interactive debugger). On the first time it asks whether the debugger
should be entered. Is that practical or would that be annoying? (I don't know).

>   - A big part of ease-of-debuggery is good error/information messages.
>     Chicken's messages aren't awful, but they also aren't great - I
>     would say that mzscheme's messages are better, for example.
>
>     > (car)
>     Error: bad argument count
>     1
>     0
>     > (car "foo")
>     Error: bad argument type: "foo"
>
>     > (car)
>     car: expects 1 argument, given 0
>     > (car "foo")
>     car: expects argument of type <pair>; given "foo"
>
>     It would be even better to see the faulty expression in the error:
>
>       Runtime error while evaluating:
>         (car 3)
>       Argument type mismatch:     argument 1
>       #<primitive-procedure car>: expects argument of type <pair>
>                                   given type <number>: 3

Yes, Chicken's error messages are pretty bad and pretty inconsistent. I have
changed the text shown on argument count errors slightly (but not much).
With debug.scm, you can see the expression in the backtrace (but only for
interpreted code, of course).

>     (Is it possible to get procedures to print something like the above
>     rather than just #<procedure>?)

That would need an extra slot in every procedure. I don't know whether I like 
that...

>     This is one area that compilers for statically typed languages often
>     handle well and consistently - not necessarily because of static
>     typing but because they have to in order to be usable.  I think it
>     would actually be worth putting some thought into a reasoned,
>     comprehensive and consistent error message scheme.

Agreed. The problem is that there is often very little information available
at runtime, partly because I wanted to keep too much overhead out of compiled
code and partly because I simply didn't show much forethought.
I'm open to suggestions, of course.

> On profiling:
>
>   - There are already some simple profiling features like (time ...)
>     that one can use to get basic performance information.  A dedicated
>     profiling feature would be a really shiny addition, though -
>     something that could provide a nice breakdown of resources used by
>     every procedure called within a form or program.

See Sven's post. The profiling stuff is somewhat hidden in the manual, but
it's there! ;-)


cheers,
felix