Try using "my" in a REPL and you won't fair any better.
Yes, I'll admit, that was quite stupid on my part.
... one would likely quite quickly find "x" which is all that is needed to make "perl -dex" a REPL.
Hmm, not sure if "perl -dex" is really a REPL now. The E in REPL standing for eval, but then oddly enough this code, when placed in a script and evaluated by perl, fails with many errors.
#!/usr/bin/perl
x @foo= 1..10;
x "@foo";
But why bother when one can instead spend that time composing a node to demonstrate how little one knows about the debugger and how uninterested one is in learning more. :)
I will freely admit I know little about the debugger, and that I am extremely uninterested in learning more about it. But that's not what the OP is talking about, he asked about a REPL, which I still maintain the debugger is very much not.
A REPL is useful for experimenting. A debugger is also useful for experimenting but is even more useful for experimenting in the context of the middle of some script or module code.
I agree a REPL is useful for experimenting, but thats a very limited view of REPLs (strangly similar to my limited view of the Perl debugger ;). A good REPL will allow experimentation within the context of a script and/or module as well, I am not sure about Ruby and Python, but the LISP, OCaml and Haskell REPLs all allow that very easily. And the OCaml REPL is even useful as a documentation tool as well. Here is an example I did just today:
Objective Caml version 3.09.3
# module L = List;;
module L :
sig
val length : 'a list -> int
val hd : 'a list -> 'a
val tl : 'a list -> 'a list
val nth : 'a list -> int -> 'a
val rev : 'a list -> 'a list
val append : 'a list -> 'a list -> 'a list
val concat : 'a list list -> 'a list
(* ... bunch of functions removed here ... *)
val merge : ('a -> 'a -> int) -> 'a list -> 'a list -> 'a list
end
By aliasing the List module I was able to get the OCaml REPL to print out the signature of the module (yes, it's a little difficult to read if you don't know OCaml, but if you do, then it's extremely informative).
As best I could tell, the closest thing in the Perl debugger is doing this:
S Foo::Bar
the output of which is not nearly as informative, but that's not the Perl debuggers fault since Perl subs don't have type signatures.
I also use the OCaml REPL regularly while developing a module to do exactly what you did with Win32:: and the Perl debugger. Here is another example session from the other day:
You will notice a couple very nice aspects such as:
- Automatically dumping out of the module signature.
Again, if you don't know OCaml, it is hard to read, but being able to see (in detail) the entire signature of my module means that I can easily spot mistakes before even writing a single line of code by just reading the function signatures.
- Multi-line input.
Sure I can do this in the Perl debugger if I escape all my newlines, but that's no fun ;)
Anyway, enough of this, there is very little you could say to convince me that the Perl debugger is a even halfway decent REPL tool. A good REPL is a powerful, and easy to use tool which is useful above and beyond simple experimentation. The Perl debugger on the other hand does not allow you write code without debugger commands sprinkled within it, and it's default output tends to skew towards ugly and only somewhat informative (to coax more from it you have to dip into those "arcane" commands again). A quality Perl REPL, which used Perl's extensive reflective capabilities to display informative output and allowed much cleaner code testing would be a welcome addition to CPAN IMO.
|