Re: [Caml-list] Do you use a debugger with OCaml? If not, why not?

[Romain Bardou <romain@cryptosense.com>]

On 25/11/2015 13:49, John Whitington wrote:
> Hi,
>
> Like, I suspect, many people, my method has always been to insert
> Printfs, and stare at code until I find the problem. In fact, the
> ocaml.org page on ocamldebug says:
>
> "In fact, for complex programs, it is likely the case that the
> programmer will use explicit printing to find the bugs, since this
> methodology allows the reduction of the trace material: only useful data
> are printed and special purpose formats are more suited to get the
> relevant information, than what can be output automatically by the
> generic pretty-printer used by the trace mechanism."
>
> So, I ask: What do you use for debugging small and large OCaml programs?
> If not a debugger, why not? What problems prevent it? How does your
> debugging process differ when writing OCaml compared with other
> languages you use?
>
> John
>

I used to program in Delphi, which is basically an IDE for Object 
Pascal. It had a debugger which I used, because it was easy:
- click in the margin of your program to set up a breakpoint;
- click on a button to run step-by-step;
- learn the keyboard shortcut for this button by putting the mouse 
cursor over it;
- view the value of a variable by putting the mouse cursor over it;
- add conditions to breakpoints easily, like "only stop after the 100th 
time" or "only stop if x > 100".

I did use the equivalent of printf sometimes though, because for some 
bugs it's just more convenient, even in a GUI such as Delphi.

I almost never used a debugger for OCaml. I tried once, but:
- the learning curve was really not as smooth;
- it was not integrated into my editor (Emacs) or if it did, it was not 
easy to discover;
- having to type debugger commands was actually slower than adding 
printf calls, maybe because I had to look up the commands first.

I'm impressed by the capacity to rewind, but it turns out this feature 
is not enough to counterbalance the above.

I would probably use a debugger for OCaml if it had the following features.

- It's an easy-to-use GUI.

- I can click to set up a breakpoint or just add something like 
Debug.breakpoint () in my code. I can run it step-by-step.

- I'm able to see the state of the stack and the heap with some kind of 
OCaml value browser. This browser should know the types of values to 
display them with constructor and field names. I should be able to click 
to open or close a value so that I can hide large subtrees. The roots 
could be the roots of the GC, or the set of variables which are 
currently in scope. I can click on a variable in my code and the browser 
jumps to it immediately.

- I can visualize the current backtrace, and use the value browser to 
explore function arguments in this backtrace.

- The state is saved at each breakpoint so I can explore the past using 
the value browser.

It would be an awesome challenge to program such a tool but it requires 
a lot of time! So I just use printf. Actually I think there has been 
work by OCamlPro which goes towards those goals.

Printf-debugging would be even easier with some kind of "typeof" 
construct, which would return a runtime representation of the type of 
its argument, so that one could easily write a generic printer without 
the need for a ppx. Even if it only worked for non-polymorphic parts of 
said type it would be useful, as long as it uses the type after 
inference has finished. For instance one could write "let print_t (x: t) 
= print_generic (typeof x) x" and get a generic printer for type t. One 
can already write a generic printer with Obj, but it misses the field 
and constructor names, that typeof could provide. The type 
representation could be from compiler-libs or something. I might try to 
patch the compiler to add that one day, just for fun because it's not 
general enough to be integrated, I guess.

Cheers

-- 
Romain