2009Q1 Grant Proposal: Interactive Perl Interpreter

Category: Grants

Comments (14)


This grant seems like it would reproduce some large portions of PPI and Devel::REPL. Also, all this in 50 hours for $1,000? That seems grossly unrealistic.


What benefits would this offer over Devel::REPL with the Devel::REPL::Plugin::MultiLine::PPI plugin?


fyi: i use zoidberg for my interactive perl needs.


Hi all! I was checking the wrong site to see when this would get posted, so I only just saw these comments. I'm at work but will respond as soon as I get a chance.


I must admit that I didn't know about PPI, and it seems clearly superior to writing my own parser. So please consider that part of the proposal changed to "use PPI to implement long lines" which now looks pretty trivial.

I had already seen Zoidberg, Psh, and a couple of other homebrew interactive interpreters. Zoidberg seems more focused on being a login shell: for instance, it doesn't return the result of evaluation by default, which means that one is constantly typing "print" on every other line (especially for one-liners). It also lacks tab completion on variables or functions.

REPL is nice. I just noticed Lexical::Persistence (a feature that I dearly wanted but couldn't find anywhere), so that's good. Unfortunately I don't find the "re.pl" script to have great defaults (for instance, it doesn't turn on any tab completion by default).

Furthermore, it seems like re.pl uses __PACKAGE__ in a strange way. That is, the input "sub abc {}" defines a function called 'abc' in the package 'Devel::REPL', but the input "abc()" tries to call 'abc' in the package 'main'. This ends up being really annoying and kind of defeats the purpose (and certainly does not comply with how perl would interpret the code).

That said, it would be possible to patch REPL to handle my issues, and it already has a reasonable feature set. At this point I am going to email the maintainer to get his opinion on this stuff.

For the purposes of this proposal, please consider the following changes:

1. use PPI to detect multi-line constructs
2. use Lexical::Persistence to allow my() to work (rather than the mapping strategy I talked about).

Those should substantially reduce the amount of work required. My apologies for failing to find them.


Erik, at this point I think the best thing to do is talk to mst (Devel::REPL maintainer), figure out what you'd like to do with Devel::REPL, and submit a new proposal for the next grant period.

Typically, a proposal that proposes to work on someone else's module will also be vetted by that other person, because if they don't want you to do the work, it's not worth approving the grant.


I'm the Devel::REPL author and you can find the team on #devel-repl on irc.perl.org

I've you don't IRC, please contact me at mst (at) shadowcat.co.uk and I'll sort you out with a commit bit and a branch to play with.

Also, your comment about __PACKAGE__ is either a misunderstanding or a bug you've failed to report. It doesn't happen for any of the users who actually talk to me.

The defaults are conservative and the --profile option allows you to pick a whole different basic setup; I think the current default one is probably "what I like" and would be happy to give consideration to a more newbie-friendly set of defaults since the feature to override them is already there.

Looking forward to speaking to you.


I don't think you are quite correct about the Devel::REPL model. If you want, ping me on #devel-repl (on irc.perl.org), and I will help you get your proposal working. I don't think it will take more than an hour, actually. Devel::REPL is very flexible once you are comfortable with the model.

Anyway, the benefit is that the Perl community gets your thing, and we still have $1000 to spend on something else!


At this point it seems clear that I should withdraw the proposal request and concentrate on talking to the Devel::REPL community. I've emailed a more detailed breakdown of my thoughts to Matt and will be heading to #devel-repl.

Thanks for all the feedback and suggestions.


Hi. just a last note saying he's here (i.e. on the channel), we've found him and it looks like we're going to have fun working together.

This should be fun! :D


Perl has an internal interpreter "eval", all perl scripts are evalled first for handle BEGIN, END blocks, it is not necesary aa extern interpreter.


You misunderstand the intent of the grant. It is to provide an /interactive/ interpreter to allow users to test things /interactively/. This is invaluable for noodling around and figuring out problematic bits of code, much like a debugger. In fact, the Perl 5 debugger has been used as a repl (another name for this kind of interpreter) for a long time, but it's lousy at it.

Many, many languages have this kind of program, and it's very useful. It is not really related at all to eval{}, BEGIN, or END.


Maybe you are right, but I need an example of how this iperl works, I dont see how it will work, and perl doesn't seems to many languages, it's unique.

The Perl Debugger, chapter 20, programming perl 3rd edition.


I´ve started learning to program with Python. The IDLE Interpreter is a very helpfully tool especially for absolutly beginners. Now I am forced to learn Perl and I really miss some Application like IDLE.
So good luck for the Project, hope i can test it very soon.


Sign in to add comment