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";
[download]

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
[download]

As best I could tell, the closest thing in the Perl debugger is doing this:

S Foo::Bar
[download]

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:

 # #use "tree.ml";;
module Tree :
  sig
    type 'a tree = {
      node : 'a;
      mutable parent : 'a tree option;
      mutable children : 'a tree list;
    }
    val create : ?children:'a tree list -> ?parent:'a tree -> 'a -> 'a
+ tree
    val is_leaf : 'a tree -> bool
    val is_root : 'a tree -> bool
    val get_depth : 'a tree -> int
    val add_child : 'a tree -> 'a tree -> unit
    val add_sibling : 'a tree -> 'a tree -> unit
    val child_count : 'a tree -> int
    val get_child : 'a tree -> at:int -> 'a tree
    val size : 'a tree -> int
    val traverse : 'a tree -> ('a tree -> 'b) -> unit
    val string_of_tree : ?buffer:int -> string tree -> string
    val tree_of_string :
      ?node_converter:('a -> 'a) ->
      line_parser:(string -> int * 'b tree) ->
      source:in_channel -> tree_root:'b tree -> unit -> 'b tree
  end
# print_string (
      Tree.string_of_tree (Tree.create "root" ~children:[
          Tree.create "1.0" ~children:[
              Tree.create "1.1";
              Tree.create "1.2";
              Tree.create "1.3" ~children:[
                  Tree.create "1.3.1";
              ];
              Tree.create "1.4";
          ];
      ])
  );;
1.0
    1.1
    1.2
    1.3
        1.3.1
    1.4
- : unit = ()
#
[download]

• 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 ;)