[plt-scheme] Dalek vs. FrTime (was: Re: Announcing MzTake: a scriptable debugger)

On Tue, 2004-08-10 at 16:02, Shriram Krishnamurthi wrote:
> Guillaume Marceau and Greg Cooper did this too (ie, using JDWP).
> They used some of the code from Ruby to bootstrap their debugger.
> We have a paper about it at ASE 2004 that you can get from my Web
> page.

Shriram,

Thanks for the pointers.  I assume you mean this paper [0].

I read it in conjunction with "A Dataflow Approach to Event-Based
Debugging"[1] and found both papers very useful.  For a variety of
reasons, I may implement a JDWP-based Java debugger in Emacs Lisp.  I
know I'm reinventing the wheel here and that mine will come out a lot
squarer than yours.  Nevertheless, I was wondering if you (or any of
your co-authors) could comment on and clarify a few points for me,
since you guys have obviously spent a lot more time thinking about
these issues than I have.

Since I'm not inclined to try to implement a functional reactive
system in elisp, I'll probably go down the simpler path of Dalek.
However, I'd like to try to leverage some of your insights, if
possible.  Hence my question: Even though your FrTime-based solution
is arguably more elegant, do you think there is any middle ground
between Dalek and FrTime?  In other words, can I do slightly better
than Dalek, even though I'm not going to go as far as FrTime?

One obvious way in which your solution is more powerful than Dalek is
that you get to leverage an existing powerful host language rather
than inventing a new crippled special-purpose little language from
scratch like Olsson et al. did.  That's a non-issue for me, as I'd be
using elisp which is obviously more expressive than a Dalek-like
little language.

Another alleged advantage of your approach is stated in the following
paragraph:

   | In Dalek, each event handler can suspend or resume the execution
   | of the target program, but these can contradict each other. Dalek
   | applies a fixed rule to arbitrate these conflicts. In contrast,
   | we let authors use set-running! to create flexible,
   | application-specific rules (for instance, by using and, or and
   | richer connectives in the expression that guards
   | execution). Indeed, using a behavior as the guard expression
   | highlights the power of using FrTime as the base language for the
   | debugger, since we can easily reconstruct Dalek's policy in our
   | debugger. This design addresses an important concern raised in an
   | analysis of Dalek by Crawford, et al. [10].

I haven't been able to find the cited reference[2] online.  Having not
read it, I'm not sure I understand the issue fully.  It seems to me
that there is a bit of an apple-to-orange comparison going on here.

Consider the following.

 (a) Dalek allows you to set breakpoints. In contrast, only
     tracepoints seem to be allowed in [0].  As far as I understand,
     these do not pause the running JVM.  The only way to actually
     pause the debuggee process is through set-running!.

     If you were to add the ability to set breakpoints, wouldn't you
     run into the same problems that Dalek has?

 (b) To compare apples to apples, consider a subset of Dalek
     restricted in three ways.  Number one, disallow breakpoints so
     that the only way to pause the debuggee process is via an
     explicit "pause" command (similar to set-running!).  Number two,
     disallow the use of "pause" in non-sink nodes.  Number three,
     only allow a single sink node.

     With these restrictions in place, Dalek would behave much like
     your example in [0], where "inserts" and "removes" are source
     nodes (both defined in terms of "trace"), "violations" is an
     internal node, and "nv" is the sink node and the only one allowed
     to use set-running!.

     Viewed this way, what's the big difference between [0] and [1]?

Thanks,
Vadim



References

0. Guillaume Marceau, Gregory H. Cooper, Shriram Krishnamurthi, and
   Steven P. Reiss.
   /A Dataflow Language for Scriptable Debugging/
    
http://www.cs.brown.edu/~sk/Publications/Papers/Published/mckr-dataflow-lang-script-debug/

1. Ronald A. Olsson, Richard H. Crawford, and W. Wilson Ho,
   /A Dataflow Approach to Event-Based Debugging/,
   http://www.cs.ucdavis.edu/~olsson/pubs/1991/dataflow.ps

2. R. H. Crawford, R. A. Olsson, W. W. Ho, and C. E. Wee.
   /Semantic issues in the design of languages for debugging./
   In Proceedings of the International Conference on Computer
   Languages, 1992.
   Available for $35 from
   http://ieeexplore.ieee.org/xpl/RecentCon.jsp?puNumber=387




P.S.

> Conceptually it doesn't look that much more clever than Tolmach and
> Appel's debugger

Tolmach is a good name for a PL wonk.  It means "interpreter" in
Russian.