Browse thread
[Caml-list] Re: Debuggers (was Jihad)
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Krishnaswami, Neel <neelk@c...> |
| Subject: | [Caml-list] Re: Debuggers (was Jihad) |
Bauer, Robert [mailto:rbauer@rational.com] wrote: > > Case in point - debugging; one advantage of the imperative paradigm > is that being based on turing machines, it provides (indeed requires) > explicit notions of state - this makes debugging easier - the ocaml > debugger is not very modern with respect debuggers for imperative > languages - even though it is leaps and bounds better than anything > available for say, haskell. I agree with some of the specific details in support of this claim, but disagree with the claim itself. Ocaml's debugger is in one respect extremely advanced: it is a reversible debugger, which puts it way ahead of most languages' debuggers, imperative or not. It is in one other respect inferior to common debuggers: you can't set conditional breakpoints (aka watchpoints) in it. I don't think that this is due to any intrinsic problem caused by Caml's functional nature, though. After all, Smalltalk and Lisp are famous for providing the ultimate in debugging environments, and both of them have higher-order functions and offer the debugger vastly less in the way of reliable type constraints than Caml does. I think (as confidently as I can without reading the source :) that it would be relatively straightforward to add that to camldebug. However, I won't add it mostly because I don't use debuggers when I have an interactive prompt available (such as the ocaml program provides), because with a toplevel it's easier to write small functions, test them right there, and compose them incrementally. -- Neel Krishnaswami neelk@cswcasa.com ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr