I have a couple of misgivings about this that go off in a couple of diverging directions.

If what you want to do is just give some sort of entertaining talk, sure. I wonder though if it might also be interesting to discuss and build on some of the existing non-dead-end avenues and might have a more lasting impact outside of a talk.

There are two existing REPL's that I know of: Devel::REPL which is more like Ruby's irb, and psh which is more for like a Perl replacment for a POSIX shell.

Installing Devel::REPL from CPAN pulls in lots of stuff including Moose which may be off-putting to some. But on the other hand, it may very well not be a problem for those who are writing Perl using modern OO Perl style. Those people may either already have it installed or want it installed. Some may simply decide to get Moose via their OS distribution mechanism.

But while Devel::REPL pulls in lots of other modules, psh does not.

So the first question: have you have considered contributing to one of these projects instead of going off in yet another direction?

And this leads me to the other aspect of this endeavor I think saddening: yet another (largely dead-end) extension of perl5db. perl5db is what I'd use as a negative advertisement for the Perl language.

Have you considered extending Devel::Trepan for a command-line debugger (which seems to be what you want here) or Devel::hdb for an HTML REST service debugger? Both of these are much more modular and come with tests.

And for having expressions evaluated, have you seen my wiki entry on how expressions are handled in Devel::Trepan?

Good luck with your talk.

My project is about building a REPL and maybe a shell on top of the debugger w/o breaking compatibility (well preferably not too much). It's not about debugging.

And my talk was already in 2012.

You should know, we already discussed: Re^3: How to do perl -c inside perl? ¹

Good luck with your project! =)

Cheers Rolf

( addicted to the Perl Programming Language)

¹) I recognized your discussion style!

I confess, I'm absent minded and make lots of mistakes. That's one reason I work on debuggers!

I clicked on the IPL link and saw the talk and didn't look at the date carefully. Sorry.

But I still come back the key nagging question, why keep pursuing this rather than incorporate it into one of the existing REPLs or more modern debuggers which can function as a REPL?

Lastly, although the sub ... trick is a clever hack, it is still a hack. Better would be to do something to more directly attack parsing which — yes I know — is hard.

But for the use you describe, it doesn't have to be perfect, and basing off of some sort of more sound framework (such as via some sort of parsing technology) it could incrementally get better in a non-hacky way for the kind of thing you want to do. And could be used for other things too.

Or instead of using some new different parsing technology, you could really start with Perl's parser (and related system) and strip it down. Sort of like what's going on with the sub hack but you have more control over everything.

I am in favor of tkdb, it is pure-perl single file debugger that depends on Tcl::Tk and is an improvement of ptkdb

In what way is it an improvement, what's better?