[Chicken-users] Debuggery

[Category 5]

Hello!

I've been meaning to say a bit about this for a while but didn't
remember until you posted debug.scm.

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.

I also think this is a perfect opportunity to make Chicken an example
that other implementations would do well to follow.  Chicken is
especially well suited to real-world work: it compiles to very portable
C with good performance, the compile-and-link process is trivial and
works transparently with shared libraries, it includes good I/O, POSIX
and networking interfaces, and has excellent and tight C integration via
the FFI.  The two big features left to look at for pragmatic development
that I can think of are debugging and profiling facilities.

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.

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

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

  - 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

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

    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.

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.

--