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.