"Michael Maraist" <[EMAIL PROTECTED]> writes:
[...]
> First, the current debugger allows multi-lines if you use "\" at the end of
> the line ( a la C ).
Thanks. TomC also pointed this out. I still don't like it, though.
(But it will be added to the next revision).
Take a look at what sh will do for you:
$ while true; do
> echo 'Infinite loop!'
> done
Since you've not finished typing in a command, it keeps going until
you have.
> Second, lexically scoped variables will dissapear on subsequent debugger
> lines since their scope is wrapped in an eval.
The RFC mentions this, perhaps not prominently enough. The ability to
muck about with variable scopes on the command line is handy, though,
when you just want to test "what X does". You're right that since you
cannot exit the "global debugger scope", it is for the most part not
very useful. But it is desirable to have a command line which
imitates the language as much as possible.
> 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 ).
Exactly. It should not.
> 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.
Benefiting the development cycle is exactly what I want to do. And if
I'm running Perl as a calculator, I'll write multi-line code. Even
today, for some massive "exploratory" file-munging I just type at the
debugger.
> 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).
Take a look at `zsh' (I should really add a REFERENCES section to the
next revision). This lets you edit your multi-line commands easily,
since the command line editor is a multi-line beast. There's even an
alias to edit text files using it floating around somewhere in the
documentation.
> 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.
Yes. `42' is the officially approved value here, for unquestionable
reasons.
> 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.
perl can parse Perl, so there's no reason for its debugger to do so
again. I "just" want Perl to provide enough hooks into its parser to
allow it to parse multi-line commands in the debugger.
> This has been it's
> biggest hypocracy as far as I'm concerned.. I'm going to make an RFC for it.
I think somebody else is planning an RFC on accessing the parser.
Note, though, that this could require an extension to the parser
access beyond "just tell me if this string is a complete legal
command"; at the very least, you must know if all extensions of the
string are syntax errors. This is different from saying if the parse
succeeded: if you have C<do {>, it's a syntax error, but can be
extended to be a legal Perl form. But if you have C<do }>, it's a
syntax error no matter how you choose to extend it.
[...]
> 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 is a separate issue, which belongs in a separate RFC. The
debugger syntax should be as close as possible to the Perl syntax; any
extensions are probably unwarranted.
[...]
--
Ariel Scolnicov |"GCAAGAATTGAACTGTAG" | [EMAIL PROTECTED]
Compugen Ltd. |Tel: +972-2-5713025 (Jerusalem) \ We recycle all our Hz
72 Pinhas Rosen St. |Tel: +972-3-7658514 (Main office)`---------------------
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555 http://3w.compugen.co.il/~ariels
