> Whenever I've wanted a Perl REPL, I've used the debugger,
let's first name some problems with that statement *
- the debugger doesn't print automatically (The P in REPL)
- the debugger is cumbersome with multi-line statements (you need to end every line with \\ )
- it fails to handle lexical variables across lines
- history and navigation isn't available out of the box
- documentation and code are arcane
I'm personally using a patched version, because I really like the
- extensibility with aliases
- it's already integrated in many IDEs.
- the possibility to run bash commands directly
- When "debugging" (i.e. analysing foreign code), I want to have the same tools at hand
The point that stopped me from publishing a forked version was that POD and code is so deeply interwoven, that I couldn't easily fix the command loop.²
So I delayed the project till I have a POD parser ready that creates a separate perl5db.pod.
Even scarier is that perl5db is using code in the main:: namespace which is not really obvious for me. I think it even dates back to the Perl4 era.
Saying this I really advocate fixing it, extending the debugger to a real REPL which comes out-of-the-box would be a great plus for the Perl universe and could even lead to a Shell replacement.
For those interested IPL: PDF and code
PS: you failed to mention other projects
footnotes
*) to have some criteria for "good" REPLs
2) The command loop, that's several hundred lines of code with regexes "parsing" commands ... but each block included the POD for that command.
How do you refactor linear code where the documentation depends on the order of the code?
I'm a fan of literate programming, but that's a good example of how not to do it.
If you keep documentation close to a subroutine, you can still move that sub, not so when interspersed linear code. |