With respect to using a debugger as a Pseudo-REPL see my blog post Devel::Trepan Debugger evaluation of Perl statements where I address things like the missing "print" in RE(P)L. Also addresssed is the fundamental fact that Perl has an array and scalar context in evaluation. The debugger also even tries to come to grips with the fact that although there's no "hash" context, because Perl has hash variables, something probably needs to be done to smooth that out. It is possible more needs to be done for subroutines, globs, and file handles.

Now back to detecting when continuation of input is warranted. The real crux of the problem as has been noted, is the lack of a Perl parser; that Perl is the only thing that can really parse Perl properly. So we have these wrapped "sub" solutions. But if you are willing to put your code in a file, then one can "eval" or "do" that file. That obviates the cut and paste problem mentioned in the slides.

But a failing of the eval approach as you note is that if there's a syntax error somewhere inside you'll never know when to stop. No suffix of the previous input will never be valid. A slight improvement might be to parse the error message to see there's something that is unambiguously unfixable. Things like "Can't find string terminator" or "... anywhere before EOF" suggest continuation. Too many things fall in the middle though.

For Devel::Trepan you could probably write your own Devel::Trepan command for multi-line input. It would be clean and you can make it a package on CPAN. At a minimum Devel::Trepan gives you cleaner ways to extend code than perl5db.

Something related to figuring out whether input should be continued is trying to show all the full statement that starts on a given line, no matter how many lines it spans. This is useful in a debugger to show the source code statement where the program is stopped.

The sub-wrapped eval heuristic has more hope here for two reasons. First, we know that the underlying text is valid. Second, if a statement spans several lines, then when that statement ends programmers don't generally start a new statement on the same line. That is, there generally isn't something like:

  
   $x 
   = 5; $y = 6;
   $z = 7;
[download]

Finally in the slides you seem to place a big emphasis on using things that are in Perl core. But for anything reasonable that is a chicken and egg problem. People have to start using, likiing and advocating Devel::Trepan before it would be put into core.

> But a failing of the eval approach as you note is that if there's a syntax error somewhere inside you'll never know when to stop. No suffix of the previous input will never be valid. A slight improvement might be to parse the error message to see there's something that is unambiguously unfixable. Things like "Can't find string terminator" or "... anywhere before EOF" suggest continuation. Too many things fall in the middle though.

ATM I'm solving this by stopping multi-line after manually typing a double semicolon ";;". I just patched the mechanism for parsing "\" at end of line.

And yes on the long run one needs a better "perl parser".

Thats why I started a spin off project for "empiric" parsing, which even works well detecting nested structures in its actual very Q&D form (mentioned in the slides)

I plan to release it on GitHub/CPAN, as soon as my actual proj€ct end$, maybe it can even help with other REPL projects.

> Finally in the slides you seem to place a big emphasis on using things that are in Perl core.

perl5db is deeply integrated in many tools, including my preferred IDE. And thankfully my patches work there out-of-the box!

And I'm regularly working on remote servers where installing new modules is very "political" ... but nobody can fire me for my personal rc-file.

I like Devel::Trepan and I can follow many of your arguments and I certainly didn't mean to attack your efforts.

But ATM there are so many shell/repl/debugger solutions on CPAN and none became core till now.

And I need solutions now.

Cheers Rolf