You list the particular commands as 'existing functionality'. I think
this is a mistake, even if you didn't mean it that way, if it was just
an artifact of your presentation format. I know that breaking
debugging habits that have been ingrained in at the spinal level may
be hard to break, but thinking that "we must save t" (or any particular
command) is in my opinion the wrong to approach a new design.
Rather, look at the higher level concepts; take a look, nay, several
looks, at other command line debuggers, what commands do they offer?
Collect and group the concepts. Take a look at graphical debuggers
(boo! hiss! I hear the chorus moaning) -- but seriously: take a look
at, say, ddd and its data displays. What kind of hooks, APIs, design,
we can supply so that making the life of "gooey looser interfaces" is
easier? Take a look at various Perl debugging books and tutorials:
what (lack of) features they apologize about? Take a look at perltrap
and similar documents, like beginners' tips and ticks: what are the
common mistakes?
Also, one current problem with the debugger should of course harass us
no more in Perl 6: the lexical scope of the debugger is different from
the scope of the debuggee. (You may have mentioned this but I didn't
see it.) The debugger must be able to see two scopes at the same time:
its own and the debuggee's.
Finally my personal pet peeve that I wish would be banished: 'h'
should give just a short summary, not the full story that needs
a pager.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
