tags:

views:

124

answers:

3

Hello, I usually use perl -de 42 for obtaining an interactive perl shell. I have seen Devel::REPL and I have seen some blogs like http://www.xenoterracide.com/2010/07/making-repl-usable.html explaining how you can enhance Devel::REPL with the plugins, but I have not used yet.

I am wondering: is it too bad to use the debugger as an interactive shell? why?

note: the disadvantages mention in this perlmonks node were limitations of the user not of the perl debugger.

Do someone know where I can read more about perl REPL?

Is Devel::REPL ready for limelight?

UPDATE: I accepted the Pedro's answer because it answered the question that I asked, but still I would like to know when and why (if any) the use of the perl debugger as an interactive shell is a bad idea compared with one of the perl REPL implementations. And which perl REPL do you prefer?

+6  A: 

One disadvantage of perl -d is that lexical variables immediately go out of scope. Example:

DB<1> my $p = 123;

DB<2> print $p;

DB<3>

From perldebug:

Note that the said eval is bound by an implicit scope. As a result any newly introduced lexical variable or any modified capture buffer content is lost after the eval. The debugger is a nice environment to learn Perl, but if you interactively experiment using material which should be in the same scope, stuff it in one linescope, stuff it in one line.

Pedro Silva
Well, I'd have to say that, in response to the question "what are the disadvantages of using the perl debugger vs a real REPL like Devel::REPL?", lexical variables not working is one answer. And actually, it causes lots of problems, not just with 5.10 features. The main one is, *it's not a real REPL*; you can't do interactive development on it.
Pedro Silva
well I am using it always without strict and with global variables. I am not doing big things, only testing APIs object returns or manipulating files and it is easier draft the oneliners in a REPL than by trial and error in the shell. Having said that, my problem with the scope is not the variables but the perl 5:10 features that are not available because the scope issue see [How to use perl 5.10 features inside the debugger?](http://stackoverflow.com/questions/3539710/how-to-use-perl-5-10-features-inside-the-debugger)
Pablo Marin-Garcia
@Pedro:from the point of view of _real REPL_ and how I formulated the question you are totally right about the variable scope. But this was a limitation that I already knew and does not affect my normal interactive usage so *in my case* this is not an issue to change to a real REPL, but not being able to use the perl5:10 features *IS*. I was more interested in knowing if there was limitations in memory usage, eficiency etc. I have not accepted your answer yet ;-) (despite it is correct), because I wanted to attract other answers that could focus in other differences more important to me.
Pablo Marin-Garcia
Fair enough... :)
Pedro Silva
+2  A: 

Rather than use the debugger and miss out on features, I tend to use just

perl -wnE'say eval()//$@'

I've used Devel::REPL and like it, but just never got used to using it.

An advantage to using the debugger is being able to have $DB::single=1 to stop and single-step at a given point.

ysth
Thanks ysth, I didn't know this trick, +1 because is nice way of starting a calculator ;-) but as an interactive shell is not very usable: no history, no readline, no 'm' option to see which methods you can call in an object, you need to use Data::Dumper instead x 1, x 2 etc, no tab expansion to see the variables used.....
Pablo Marin-Garcia
@Pablo: [rlwrap](http://utopia.knoware.nl/~hlub/rlwrap/#rlwrap) works wonders for history and readline support.
Pedro Silva
@Pedro: thanks, this is a nice tool to know.
Pablo Marin-Garcia
+1  A: 

Both have different goals. The debugger is optimised for debugging an already written Perl script/program. Whereas a REPL primary objective is to provide quick language feedback and is optimised for (the developers) interactive input.

For eg. If I do the following in the Perl debugger:

DB<1> for my $x (1..10) {

I get a Missing right curly or square bracket at (eval 5)... error.

Whereas with Devel::REPL it allows multiple line input:

$ for my $x (1..3) {
> say $x;
> }
1
2
3

I thoroughly recommend Devel::REPL and with the extra plugins it becomes a handy development tool to have running beside your editor.

/I3az/

draegtun
I think that with the right plugins Devel::REPL would be a nice tool. Is nicer to hit only <enter> than ' \<enter>' at the end of running lines in the debugger.
Pablo Marin-Garcia
I found that pdl2 (the interactive shell for PDL) is using now Devel::REPL and load a lot of plugins: $ pdl2Perldl2 Shell v0.004Loaded plugins: Commands Completion CompletionDriver::Keywords CompletionDriver::LexEnv CompletionDriver::Methods DDS FindVariable History Interrupt LexEnv MultiLine::PPI NiceSlice PDLCommands Packages PrintControl ReadLineHistory. NICE!!
Pablo Marin-Garcia
Yes `pdl2` uses `Devel::REPL` if its installed otherwise it fallsback to `perdl` (PDL's original REPL). `PDL` and `Devel::REPL` are indeed a nice marriage!!
draegtun
@draegtun: yes indeed! thumbs up for PDL+Devel::REPL
Pablo Marin-Garcia