I'll be brief because windows just crashed on me.
First, the current debugger allows multi-lines if you use "\" at the end of
the line ( a la C ).
Second, lexically scoped variables will dissapear on subsequent debugger
lines since their scope is wrapped in an eval. For the most part, the
debugger is assuming that you're not using strict (and even if you did try
it, strictness would fall out of scope ). Therefore there's little reason
for lexically scoped variables, except possibly for typed variables.. But
even then, that only benifits the development cycle, since you're arguably
not going to write massive code in a debugger. Currently scalar typeing
severs no real additional purpose, since pseudo-hashes (the closest you
currently get), work fine as long as the hash-prefix is present in the
array.
Next, there's something to be said for writing an entire function / for-loop
on a single line.. And that's easy history substitution. When you're in the
debugger, you're obviously trying to debug something. Which means trial and
error... Lots of it. I can't tell you how frustrating it is when I cut and
past code into a SQL or python prompt only to be reminded that I can't make
useful use of the history mechanism. Putting lots of code on one line means
you can up-arrow, Control-arrow over to the next attempted change, then hit
enter, very efficiently. The closest you can come in the other's is to open
an emacs window and cut / paste (which has it's advantages too).
Next, learn a neat optimization:
perl -de 42
becomes:
perl -de0
You're just saying evaluate 0, or 42, or what-ever.. Which is just an
ignored op-code.
Next, it would be possible to extend the existing DBI module or create your
own (obviously a non-trivial task), then specify the new debugger on the
command line:
perl -d:debugger_name -e0
Now for the fun part. In order to achieve a truely interactive interpreter
like sh, xsql, python or lisp, you need the interpreter to be able to
understand the context of what you're typing. bash, for example, knows when
you have mis-matched quotes, or the here-document, and prompts you for more
text accordingly.
In perl, however, there is no easy way to parse perl. This has been it's
biggest hypocracy as far as I'm concerned.. I'm going to make an RFC for it.
Essentially, you have this all powerful lexer / parser that's always there..
But you can never use it.. You can only invoke eval, which isn't always what
you want. In this case, we want to be able to simply determine matched-ness
of code. This is a highly complex problem, since parenthesis, braces may be
within quotation.. And it gets even more complex because quotation could
occur within q{ ... } braces, or even worse / ... / and < ... > braces. It
is impossible to figure out the context of perl.. without running perl.
Hense the hack of making every line (including escaped multi-lines) it's own
expression, transparently.
You are correct in that changing this would require help from the core. But
a change such as this should really help more than just a simple debugger.
Take the following as an example.
#Config-file
$var = [ "ab[dsfsdf]]]", { a => 1, b => [ 1,2, 4 .. 8 ] }, system( "rm
/etc/passwd" ) ];
I often write configuration files for code. But I fear actually evaluating
configuration data (even in tainted mode). The end result is that I come up
with my own syntax which I parse with reg-exs. Sadly I find myself
reproducing the complexity of hashes / arrays needlessly. Ideally, I would
like to parse perl-like syntax but apply my own meaning to the parsed data.
Such an extension of the perl-parser could definately be applied to a
debugger..
This seems really complex and full of problems, so what I would probably
suggest is to write an extension of DB.pm that runs a syntax checker on the
line (in a manner similar to "perl -c"). Then it intelligently listens to
error.. If they are matching-based errors, then it should automatically
prompt a continuation line. Otherwise give up in failure, reporting
what-ever errors. Control-G/D should be available to break out if the
developer figures something is wrong with a continuation. This seems
deceptively simple.. But it's worth suggesting.
-Michael
