Drop the "my". The @foo you created and assigned to was local (erm ... lexical) to that one line! There is no way I know of to keep the lexical variables in scope for several separate REPL iterations.
| [reply] |
Try using "my" in a REPL and you won't fair any better.
Yes, yes, I know, with some arcane commands and such I can get the debugger to do those thing, but why should I have too?
Yes, yes, I know, if one bothers to even take a few minutes to look up just the barest of information about these "arcane" commands, one would likely quite quickly find "x" which is all that is needed to make "perl -dex" a REPL. 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. :)
% perl -dex
DB<1> x @foo= 1..10
0 1
1 2
2 3
3 4
4 5
5 6
6 7
7 8
8 9
9 10
DB<2> x "@foo"
0 '1 2 3 4 5 6 7 8 9 10'
DB<3>
But seriously, a debugger is so not a REPL.
No, it is much more useful. It is just trivial to use it as a REPL and is always handy on any standard Perl installation.
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.
When I wrote each Win32API:: module I would use the Perl debugger to experiment with the API that I had just wrapped in order to document it properly (the official API documentation was usually vague about several interesting points, for example).
| [reply]
[d/l] |
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.
| [reply]
[d/l]
[select] |
You do make some valid points, but I take exception with the following:
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
using the debugger in this context doesnt require a single debugger command. the x command mentioned in the nodes above helps to print out simple data structures, but that can just as well be accomplished using plain old print statements or (a method I'm fond of) the Data::Dumper module.
Just my $0.02
__________
Systems development is like banging your head against a wall...
It's usually very painful, but if you're persistent, you'll get through it.
| [reply]
[d/l]
[select] |
| [reply] |
% perl -de x
...
main::(-e:1): x
but the space is optional. You can also use perl -debug but not perl -dem, perl -des, perl -deq, nor perl -dey.
| [reply]
[d/l]
[select] |
but you still have to type "x " every time! What's missing is an option to include it automatically in front of every line!
UPDATES: see also using perldebugger as REPL?
| [reply] |
If that is the only thing that is missing to make the debugger worthy of the "REPL" tag, then I really fail to see the problem. I was hoping somebody would be able to explain why "a real REPL" is so much better at being a REPL than the debugger, but I have only seen hand waving and 'x' not being the default. So I consider myself still uninformed (and thus unconvinced).
A patch to allow 'x' to be the default would be interesting. If nothing else, it might trigger explanations as to why it still didn't create "a real REPL".
| [reply] |