Skip to content
This repository


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
tree: 7773368bca
Fetching contributors…


Cannot retrieve contributors at this time

file 68 lines (49 sloc) 2.648 kb
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67
This file contains a braindump of near-future directions in which to take
the debugger.

= Actual features

- Binding. Handling 'my $a; my $b := 2; # $a == 2' correctly.

- Make an interactive shell that can step back and forth between ticks, and
  inspect values, or make even more detailed queries.

- C<if> statements.

- C<while> loops. Work out how the ticks behave for both of these.

- Functions and function calls. The smallest-that-work are probably functions
  without a signature and without return statements. A return value would be
  nice, though. The function needs to have its own pad, etc.

= Architecture

- Factor out the compilerish things into a separate project, and call that
  'Yapsi'. APIs become good after about three clients have been implemented
  for them. Yapsi's three clients are this debugger, a coverage tool, and
  a static analyzer.

- Figure out a way to encode which AST nodes correspond to which substrings
  of a program. The main purpose of this is to be able to indicate the point
  of execution in the program. It is important to be able to do this on
  the granularity level of a sequence point, not just a statement. The most
  intuitive way to show this is probably to highlight the piece of code to
  be evaluated between the current sequence point and the next.

- Consider creating a dedicated instruction code, rather than running off
  the AST the whole time. The statement 'my $a = ++$a' could be represented
  by something like this:

    $0 = fetch '$a'
    $1 = add $0, 1
    store '$a', $1
    store '$a', $0

  The above represents unoptimized code as it would be generated from the
  AST of the statement.

  We could call the instruction code 'SIC': serialized instruction code.
  Or something.

  The nice thing is that sequence points can probably be collected without any
  extra tagging; just make a new one at every 'set-value' instruction.

  What does need to be tagged, however, is sufficiently precise information
  about which piece of original program a given piece of SIC corresponds to.
  Again, for the example statement, it could look something like this:

    `at line 1, column 9..13 ('++$a')
    $0 = fetch '$a'
    $1 = add $0, 1
    store '$a', $1
    `at line 1, column 0..13 ('my $a = ++$a')
    store '$a', $0

  ('at' can also be seen as standing for 'annotation'.) Note how the
  annotations occur after each sequence point except the last one.

  [Uh, it occurs to me that the line '$2 = add $1, 1' wouldn't handle an
  overridden prefix:<++> correctly. Actually '++$a' needs to be treated as
  a function call, one which could possibly be inlined. Hm, tricky.]
Something went wrong with that request. Please try again.