[ANNOUNCE] CPANPLUS-0.050_01
Greetings, After a prolonged period of merely bugfixes, this day marks the release of a new feature release (and ground up rewrite) of CPANPLUS: 0.050_01 This feature release prepares us for the next line of plugins in CPANPLUS, which should greatly improve the quality of code and use of CPAN and CPAN modules. Some of the features include: * Native Module::Build support * Native testers.cpan.org query/report * Native signature verification support * Multiple frontend shells * Scriptable shells * Improved configuration options * Improved Programmable API * Plugins to package managers * Support for a remote CPANPLUS::Daemon * and many more... You can view the readme here: http://codebase1.xs4all.nl/~kane/CPANPLUS-0.050_01.README And obtain the source from: http://codebase1.xs4all.nl/~kane/CPANPLUS-0.050_01.tar.gz or soon on a CPAN near you... This beta release has already had extensive testing from a dedicated group of people on #perl-qa and #p5p, but the time has now come to offer this beta to the wider public, before declaring it 'stable' and uploading it as such to the CPAN. Therefor I invite all of you who have an interest in CPAN modules, to try this release out and report your findings back to us, whether they be feature requests, or bug reports; Feature requests: [EMAIL PROTECTED] Bug reports:[EMAIL PROTECTED] I have to again thank all the people who've so vigorously and selflessly spent great amounts of energy on making this new release possible; I think you know who you are :) -- Jos Boumans 'Real programmers use cat a.out' CPANPLUShttp://cpanplus.sf.net
perlhash iter busted
Test case attached. - Sam Ruby Index: t/pmc/perlhash.t === RCS file: /cvs/public/parrot/t/pmc/perlhash.t,v retrieving revision 1.48 diff -u -r1.48 perlhash.t --- t/pmc/perlhash.t1 Oct 2004 21:16:52 - 1.48 +++ t/pmc/perlhash.t3 Dec 2004 19:18:51 - @@ -19,7 +19,7 @@ =cut -use Parrot::Test tests = 36; +use Parrot::Test tests = 37; use Test::More; output_is(CODE, OUTPUT, Initial PerlHash tests); @@ -1215,4 +1215,19 @@ 0 OUTPUT +output_is( 'CODE', 'OUTPUT', iter); +##PIR## +.sub __main__ @MAIN +new P0, .PerlHash +set P0['a'], 'x' +iter P1, P0 +shift P2, P1 +print P2 +print \n +end +.end +CODE +a +OUTPUT + 1;
Re: Python is not Java...but will Perl 6 be?
John Siracusa skribis 2004-12-03 14:05 (-0500): I'd like to be able to s/Python/Perl 6/ above, but after many discussions on this topic, I'm still not sure if I can. Anything can be anything. I'm sure that despite the ability to run all the code you want upon reading/writing an attribute, some people will still write setters and getters. Would it be Perl if it dictated any of these approaches? Juerd
Re: Python is not Java...but will Perl 6 be?
On Fri, 3 Dec 2004 20:37:40 +0100, Juerd [EMAIL PROTECTED] wrote: John Siracusa skribis 2004-12-03 14:05 (-0500): From http://dirtsimple.org/2004/12/python-is-not-java.html In Java, you have to use getters and setters because using public fields gives you no opportunity to go back and change your mind later to using getters and setters. So in Java, you might as well get the chore out of the way up front. In Python, this is silly, because you can start with a normal attribute and change your mind at any time, without affecting any clients of the class. So, don't write getters and setters. I'd like to be able to s/Python/Perl 6/ above, but after many discussions on this topic, I'm still not sure if I can. Anything can be anything. I'm sure that despite the ability to run all the code you want upon reading/writing an attribute, some people will still write setters and getters. I guess I wasn't asking if it would be possible (I think that's been established), but if it would be easy, reasonable, or clean (as it appears to be in Python, although I'm just going by what the quoted web page says). I recall some discussions about the best way to this in Perl 6, but don't recall if it converged on anything nice. Anyway, I thought it was interesting to see the ease of forward compatibility for simple attributes touted as a feature of Python. I'd like to tout it as a feature of Perl 6 too, because I also hate writing getters and setters... :) -John
Re: Python is not Java...but will Perl 6 be?
John Siracusa skribis 2004-12-03 14:46 (-0500):
Anyway, I thought it was interesting to see the ease of forward
compatibility for simple attributes touted as a feature of Python. I'd
like to tout it as a feature of Perl 6 too, because I also hate writing
getters and setters... :)
Of course it's a feature. Having lvalue attributes means you don't have
to replicate all scalar lvalue methods to get all functionality without
copying. IMO, This is even better than in Python, with its constant
variables.
Let me demonstrate:
$foo.bar .= foo
$foo.bar ~~ s:e/foo/bar/;
$foo.bar.=reverse;
my $quux := $foo.bar;
$quux = 1;
versus:
$foo.set_bar($foo.get_bar ~ foo);
$foo.set_bar(do { (my $temp = $foo.get_bar) ~~ s:e/foo/bar/; $temp });
$foo.set_bar($foo.get_bar.reverse);
my $quux # ... ehm, right. Let's see. I think it's something like:
will STORE { $foo.set_bar($_) }
will FETCH { $foo.get_bar };
$quux = 1;
Juerd
Re: Python is not Java...but will Perl 6 be?
Juerd skribis 2004-12-03 21:09 (+0100): $foo.bar .= foo Meant ~= there. Juerd
Re: Python is not Java...but will Perl 6 be?
On Fri, 3 Dec 2004 22:06:43 +0100, Paul Johnson [EMAIL PROTECTED] wrote: http://www.nntp.perl.org/group/perl.perl6.language/9576 Wow, that's a blast from the past. I wonder how much of it is still valid... :) -John
Yet more on angle quotes
How equivalent are and «? Does use of one idiom imply the closing quote is the same. ie are the following allowed, prohibited or what? list of words» «list of words Just thinking... Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst Services
Re: Yet more on angle quotes
Richard Proctor skribis 2004-12-03 21:27 (+): How equivalent are and «? This question has already been asked. See message [EMAIL PROTECTED]. Juerd
specifying the key Type for a Hash
A6 included examples of syntax for specifying the type of the key for a hash: my %pet is Hash(keytype = Str, returns = Cat) None of the synopses have anything like this. S6 talks about the types of values, but not keys. Oversight, or is this syntax dead? --abhijit Abhijit Mahabal http://www.cs.indiana.edu/~amahabal/
Re: specifying the key Type for a Hash
On Fri, Dec 03, 2004 at 05:23:56PM -0500, Abhijit Mahabal wrote: : A6 included examples of syntax for specifying the type of the key for a : hash: : : my %pet is Hash(keytype = Str, returns = Cat) : : None of the synopses have anything like this. S6 talks about the : types of values, but not keys. Oversight, or is this syntax dead? S9 talk about it. We current have things like: my Cat %pet is shape(Str); and parameters to types are in square brackets, so it's more like: my %pet is Hash[:shape(Str) :returns(Cat)]; Larry
Re: specifying the key Type for a Hash
On Fri, 3 Dec 2004, Larry Wall wrote: : None of the synopses have anything like this. S6 talks about the : types of values, but not keys. Oversight, or is this syntax dead? S9 talk about it. Oops. Sorry. So it was oversight after all :) --abhijit Abhijit Mahabal http://www.cs.indiana.edu/~amahabal/
Re: Python is not Java...but will Perl 6 be?
On Fri, Dec 03, 2004 at 04:13:01PM -0500, John Siracusa wrote: : On Fri, 3 Dec 2004 22:06:43 +0100, Paul Johnson [EMAIL PROTECTED] wrote: : http://www.nntp.perl.org/group/perl.perl6.language/9576 : : Wow, that's a blast from the past. I wonder how much of it is still : valid... :) Almost all of it, except for details like is public. Just because A12 didn't come out till this year doesn't mean we weren't talking about those things ever since 2000. I knew that attributes wanted to look like $.foo since before Apocalypse 1, for instance. Larry
Re: flip flop xx Inf
Juerd writes: What happens to the flip flop operator? Will .. in scalar context remain the same? What comes in place of ...? (An adverb?) The scalar range operator was always a weird one for me, but that isn't to say that it hasn't been put to good use by wizards. I wouldn't be surprised if it stayed. On the other hand, I wouldn't be surprised if it left. Anyway, to answer what I _do_ know, isn't .. exactly the same as ... in Perl 5? That was my impression, at least (I've never used the latter in practice, but my little test script seems to work). Anyway, in Perl 6, list .. is your good old Perl 5 .. with lazy semantics. If you do ... in term position, you get a yada-yada-yada term, which dies if you execute it. If you do ... in operator position, you get the equivalent of ..Inf. say for 1...; 1 2 3 4 5 . . . Luke
Re: Python is not Java...but will Perl 6 be?
John Siracusa writes: I guess I wasn't asking if it would be possible (I think that's been established), but if it would be easy, reasonable, or clean (as it appears to be in Python, although I'm just going by what the quoted web page says). I recall some discussions about the best way to this in Perl 6, but don't recall if it converged on anything nice. It converged on the core-like way returning an anonymous object with STORE and FETCH methods is ugly, but it should be easy to provide nice wrappers around it. Those nice wrappers are probably going to end up in the standard dialect. Perl 6 is going to be better with opacity than any other language I know of. We're aware that lying about what's really going on is a useful thing to do. So we give you the chance to be as poker-faced about your internals as you like. ... Not that the user can't read your ass if he tries hard enough :-) Luke
Re: Python is not Java...but will Perl 6 be?
On Fri, Dec 03, 2004 at 02:05:16PM -0500, John Siracusa wrote: From http://dirtsimple.org/2004/12/python-is-not-java.html In Java, you have to use getters and setters because using public fields gives you no opportunity to go back and change your mind later to using getters and setters. So in Java, you might as well get the chore out of the way up front. In Python, this is silly, because you can start with a normal attribute and change your mind at any time, without affecting any clients of the class. So, don't write getters and setters. I'd like to be able to s/Python/Perl 6/ above, but after many discussions on this topic, I'm still not sure if I can. http://www.nntp.perl.org/group/perl.perl6.language/9576 -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: flip flop xx Inf
On Sat, Dec 04, 2004 at 01:11:30AM +0100, Juerd wrote:
: What happens to the flip flop operator? Will .. in scalar context remain
: the same?
I don't think so. It's definitely a candidate for a longer
Huffmanization simply in terms of frequency of use. On top of which,
almost no Perl 5 programmers even know what it does. Plus it's
basically opaque state in the pad. Not that opaque is bad when you
want the abstraction, but I would characterize the state of scalar ..
as almost sneaky state.
Plus we have the problem that we don't have a $. variable anymore,
nor really the concept of last input handle. I expect the p5-to-p6
translator will have to detect any references to $. and set some
kind of global $*LASTIN handle on input, and define p5dot to
be $*LASTIN.chunknum or some such. Then the flip flop might be done with
a real state variable.
So Perl 5's
if (1..10) {...}
could look something like this:
if flipflop(state $x, { p5dot() == 1 }, { p5dot() == 10 }) {...}
Pity it clobbers the current lexical scope with the name $x. Now we
see that it'd be cool to have an anonymous state variable somehow:
if flipflop(state, { p5dot() == 1 }, { p5dot() == 10 }) {...}
That would let us have a state variable that is attached to our scope but
that is nevertheless only named within the flipflop function.
Of course, if flipflop were a macro, that could easily be reduced to
if flipflop(p5dot() == 1, p5dot() == 10) {...}
or even, if you get fancy with the macro:
if flipflop 1, 10 {...}
But then we lose the flexibility of writing any of:
if flipflop(state, { p5dot() == 1 }, { p5dot() == 10 }) {...}
if flipflop(my, { p5dot() == 1 }, { p5dot() == 10 }) {...}
if flipflop(our, { p5dot() == 1 }, { p5dot() == 10 }) {...}
to control when the state gets reset, or who can reset it. So I'd
guess there's a *flipflop builtin function, and we let people define
a macro if they want it sugary, or sugarier, or sugarierier.
Or if people carp too much, we go ahead and give them a macro too. Call
it p5dotdot or some such.
: What comes in place of ...? (An adverb?)
Presumably a named arg of some sort, maybe
if flipflop(state, { p5dot() == 1 }, { p5dot() == 10 }, :after) {...}
or some such.
Now I'm trying to figure out the uses of a closure that ends with:
return \state;
That would allow a caller to change my state without me keeping track
of it at all. Works sort of a like a (void*) that's reserved for
the user. On the other hand, if it's returning a bare state it's
not gonna be very good at returning anything else useful. But maybe
return $value, \state;
has something useful in it.
Larry
Re: Python is not Java...but will Perl 6 be?
On 2004-12-03 at 14:46:16, John Siracusa wrote: Anyway, I thought it was interesting to see the ease of forward compatibility for simple attributes touted as a feature of Python. I'd like to tout it as a feature of Perl 6 too, because I also hate writing getters and setters... :) Amen. Which reminds me, what ever happened to POOL? You there, Simon? -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: flip flop xx Inf
Luke Palmer [EMAIL PROTECTED] writes: Juerd writes: What happens to the flip flop operator? Will .. in scalar context remain the same? What comes in place of ...? (An adverb?) Anyway, to answer what I _do_ know, isn't .. exactly the same as ... in Perl 5? That was my impression, at least (I've never used the latter in practice, but my little test script seems to work). Not exactly. From perlop: In scalar context, .. returns a boolean value. The operator is bistable, like a flip-flop, and emulates the line-range (comma) operator of sed, awk, and various editors. Each .. operator maintains its own boolean state. It is false as long as its left operand is false. Once the left operand is true, the range operator stays true until the right operand is true, AFTER which the range operator becomes false again. It doesn't become false till the next time the range operator is evaluated. It can test the right operand and become false on the same evaluation it became true (as in awk), but it still returns true once. If you don't want it to test the right operand till the next evaluation, as in sed, just use three dots (...) instead of two. In all other regards, ... behaves just like .. does. So it's a bit obscure. :-) Jon
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Fri, Dec 03, 2004 at 06:43:05PM +, Herbert Snorrason wrote:
: This whole issue kind of makes me go 'ugh'. One of the things I like
: best about Perl is the amazing simplicity of the input construct.
Hmm.
while () {...}
for .lines {...}
Looks like a wash to me.
: Replacing that with something that not only is object oriented, but on
: top of that also LOOKS object oriented is bound to be a loss. It's
: going to be that bit longer to write, and not the least bit easier to
: understand.
Really? I dare you to show those two lines to any random
computer-literate but non-Perl-speaking stranger and see which one
they understand better.
And actually, .lines *wins* on keystrokes if you count shift keys.
: Neither the conceptual input operator nor the extremely
: handy idiom for behave like a Unixy filter should go. Please.
It's all cargo cult at that level anyway, so whether it looks OO or not
is really completely immaterial to its usability.
If .lines loses out, it won't be because of any of your arguments, but
because $*ARGS maybe shouldn't be the topic of Main. But $*ARGS is
most certainly an object of some sort, whether or not we hide that fact
from the cargo culters.
: If you don't like the angles doing it, by all means take them. But
: don't push that far into OO land. There's a reason we aren't all using
: Python and Ruby by now.
Sounds to me like you're just allergic to dots.
And I don't buy the nuclear blackmail argument either. I'll start
worrying about people switching to Python and Ruby when those languages
get a clue about how natural languages work. As far as I know, there's
little notion of topics in those languages as of yet. (Though I wouldn't
be surprised if other languages eventually adopt our invocantless .foo
notation. For the price of one character, we document exactly which
functions default to $_. In Perl 5 you just have to memorize the list.)
But as I say, I'm not yet convinced $*ARGS should be the topic.
It would only be the topic outside of the main loop, and people would
wonder why .lines gives them a different answer in another location.
That's the real problem with it. So you'll probably get your wish
of some non-OO-looking syntactic sugar. Might even just be a global
multi sub that defaults to $*ARGS:
multi sub *lines (IO ?$handle = $*ARGS) {...}
multi sub *lines (Str $filename) {...}
multi sub *lines (IO @handle) {...}
multi sub *lines (Str @filenames) {...}
Then the filter call would be quite hypoallergenic:
for lines {...}
Interestingly, though, you can also call it as $fh.lines if you like.
Or even if you don't.
Larry
Re: flip flop xx Inf
On Fri, Dec 03, 2004 at 05:37:54PM -0700, Luke Palmer wrote: : Juerd writes: : What happens to the flip flop operator? Will .. in scalar context : remain the same? What comes in place of ...? (An adverb?) : : The scalar range operator was always a weird one for me, but that isn't : to say that it hasn't been put to good use by wizards. I wouldn't be : surprised if it stayed. On the other hand, I wouldn't be surprised if : it left. It's leaving syntactically but not semantically. : Anyway, to answer what I _do_ know, isn't .. exactly the same as ... in : Perl 5? That was my impression, at least (I've never used the latter in : practice, but my little test script seems to work). I think you'll find there's a difference between perl -ne 'print if 2..2'; perl -ne 'print if 2...2'; But as they say: When all else fails, read the directions. :-) : Anyway, in Perl 6, list .. is your good old Perl 5 .. with lazy : semantics. Yes, but it has to do that in scalar position now too, since it constructs a lazy Range object. That's the strongest argument for changing Perl 5's flipflop to some other syntax, actually. (I thought about putting it into the other message I was composing, except I was driving at the time I thought of it, and forgot it by the time I got back to the house. But hey, I'm getting old enough I can start blaming it on senility, right?) Larry
[PATCH]
This patch fixes some warnings in global_setup.c and embed.c. All it
does is add some necessary includes to pick up function declarations and
constify a variable to avoid warnings about casting from const to
non-const, so it should be pretty safe to apply.
-garrett
Index: src/embed.c
===
RCS file: /cvs/public/parrot/src/embed.c,v
retrieving revision 1.124
diff -u -r1.124 embed.c
--- src/embed.c 2 Dec 2004 10:48:18 - 1.124
+++ src/embed.c 4 Dec 2004 02:51:14 -
@@ -208,7 +208,7 @@
#ifdef PARROT_HAS_HEADER_SYSMMAN
int fd = -1;
#endif
-char *fullname;
+const char *fullname;
if (filename == NULL || strcmp(filename, -) == 0) {
/* read from STDIN */
Index: src/global_setup.c
===
RCS file: /cvs/public/parrot/src/global_setup.c,v
retrieving revision 1.54
diff -u -r1.54 global_setup.c
--- src/global_setup.c 4 Nov 2004 18:46:10 - 1.54
+++ src/global_setup.c 4 Dec 2004 02:51:14 -
@@ -24,6 +24,10 @@
#define INSIDE_GLOBAL_SETUP
#include parrot/parrot.h
+#include ../encodings/fixed_8.h
+#include ../charset/ascii.h
+#include ../charset/binary.h
+
/* These functions are defined in the auto-generated file core_pmcs.c */
extern void Parrot_initialize_core_pmcs(Interp *interp);
extern void Parrot_register_core_pmcs(Interp *interp, PMC *registry);
temp $var;
my $var=foo;
{
temp $var;
say $var;
}
would it be undef or foo? if the former, how could I make $var to
contain a copy of original content?
using analogy with my $x = $x, that's not going to work..
temp $var = $OUTER::var?
OTOH,
my @a = ... # something not lazy with 10_000_000 elements..
{
temp @a; # ouch! temporal clone!
}
that could hurt..
Re: temp $var;
On Sat, Dec 04, 2004 at 06:01:45AM +0300, Alexey Trofimenko wrote:
:
: my $var=foo;
: {
: temp $var;
: say $var;
: }
:
: would it be undef or foo?
It's undef if we follow Perl 5. (Early Perls actually kept the original
value, but that was deemed improper at some point.)
: if the former, how could I make $var to
: contain a copy of original content?
: using analogy with my $x = $x, that's not going to work..
:
: temp $var = $OUTER::var?
That's presumably correct if we take my as the prototype. Though
temp is just an operator, not a declarator, and depending on order
of evaluation it's possible that
temp $var = $var
might do the right thing. Then again, it might not.
: OTOH,
:
: my @a = ... # something not lazy with 10_000_000 elements..
: {
: temp @a; # ouch! temporal clone!
: }
:
: that could hurt..
Perl 5 actually localizes a binding when you do that rather than
copying. Perl 6 can presumably distinguish binding from copying,
so we probably need to encourage people to bind temporarily rather
than assigning. And bare
temp @a;
would be taken as equivalent to
temp @a := ();
Larry
state vs my
for 1..10_000_000 {
my ($a,$b,$c) = ...
...
}
vs.
for 1..10_000_000 {
state ($a,$b,$c) = ...
...
}
latter looks like it would run faster, because no reallocation envolved
here.
I've read an advice somewhat like that in Ruby docs, tried it on perl5,
and it really makes a difference, especially on very short loops.
could it be done some tricky optimisation, so if some variable in loop
isn't going to have references on it, stored somewhere outside the block,
than Cmy before it will be changed to Cstate?
Re: Angle quotes and pointy brackets
On Tue, 30 Nov 2004 14:58:13 -0800, Larry Wall [EMAIL PROTECTED] wrote:
But then it's not a general iterator iterator. Plus it has the Unicode
taint...
Back to reality, another thought to weave in here is that something
like
for $iterator.each - $x {...}
might specify that there may be ordering dependencies from loop
iteration to loop iteration, whereas (since junctions are inherently
unordered) saying:
for $iterator.all - $x {...}
explicitly tells the system it can parallelize the loop without worrying
about interation between iterations.
I've been thinking about it, and this strikes me as really odd. Perl 5
is full of nice shortcuts. One of them is:
for (@array) {
which takes the place of
for (my $i = 0; $i @array; $i++) {
which is what you'd have to do in a lot of other languages. What I
mean is that Perl takes an array and makes an iterator out of it.
Sure, you probably don't think about it like that, but the behavior is
the same (who says arrays need to iterate starting at element zero?).
Java just introduced something similar in 1.5.
The odd thing is that here we are designing Perl 6, and we're trying
to take an iterator and make it into an array so that we can turn it
back into an iterator again. It seems like we should just use it as an
iterator::
for $iterator - $elem { ... }
Your message leads me to believe that
for all(1, 2, 3) - $num { ... }
is already a special case that will or can be recognized and
optimized. If so, having special behavior for an iterator shouldn't be
much more difficult (though I'm not sure of the correctness or full
ramifications of this statement).
That would have the added benefit of letting me write this:
for open($filename) or die - $line { ... }
which I like. A method could be used for retrieving the next
line/char/byte/whatever:
my $fh = open $filename or die;
my $line = $fh.next
where C.next splits on the input record separator. C.next_byte and
family could be implemented on top of that as well.
The biggest problem I see (and I may just be blind) is that
for $iterator - $x { ... }
is slightly ambiguous to the programmer, which makes me want angle
brackets back. Other syntax could be used (though we seem to be
drawing a blank there), but I don't like the idea of using a method
(see Iterator-Array-Iterator above).
I also like the idea of general iterators. Really like it. Perl 5 had
it via Ctie, but it wasn't so pretty. Supposing
class Filehandle does Iterate; # Iterate or Iterator?
we have an easy way to create new iterators. I'm not sure how useful
they would be in Perl 6 (how do iterators compare to lazy lists?), but
I can see if being useful.
For instance, perhaps a more idiomatic DBI could be written like this:
my $sth = $dbh.prepare('SELECT * FROM foo');
for $sth.execute.iter - $results { ... }
Which be even cuter like this (I think):
for iter($sth.execute) - $results { ... }
where iter creates an Iterator object that just knows to call C.next
on its argument.
Anyway, take it for what its worth. I'm aware of how ridiculous many
of the things we (that includes me) say are, but perhaps I've said
something useful.
Hoping I haven't removed all doubt of my foolishness,
--
matt diephouse
http://matt.diephouse.com
Re: state vs my
On Sat, Dec 04, 2004 at 06:31:35AM +0300, Alexey Trofimenko wrote:
:
: for 1..10_000_000 {
: my ($a,$b,$c) = ...
: ...
: }
:
: vs.
:
: for 1..10_000_000 {
: state ($a,$b,$c) = ...
: ...
: }
:
: latter looks like it would run faster, because no reallocation envolved
: here.
No reassignment either, since assignment to a state declaration only
happens at first time. If you expect $a, $b, and $c to get new values
each time through the loop, you'll be disappointed.
: I've read an advice somewhat like that in Ruby docs, tried it on perl5,
: and it really makes a difference, especially on very short loops.
: could it be done some tricky optimisation, so if some variable in loop
: isn't going to have references on it, stored somewhere outside the block,
: than Cmy before it will be changed to Cstate?
Er, how did you try a state variable in Perl 5? It doesn't have state
variables...
Perl 5 already stores all the lexicals in the pad for the entire
subroutine. There is no separate pad for the inside of the loop.
Any differences in performance would be related to the actual
reinitialization of the lexical, not allocation.
So optimizing to a state variable won't necessarily help your loop
overhead, but it could help your subroutine overhead, at least in Perl
5, if Perl 5 had state variables. Best you can do in Perl 5 is an
our variable with an obscure name.
Larry
Re: state vs my
Larry Wall [EMAIL PROTECTED] wrote: So optimizing to a state variable won't necessarily help your loop overhead, but it could help your subroutine overhead, at least in Perl 5, if Perl 5 had state variables. Best you can do in Perl 5 is an our variable with an obscure name. my $x if 0; I know it's *going* away, but it hasn't *gone* away yet. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I might be an idiot, but not a stupid one. --c.l.p.misc (name omitted to protect the foolish)
