Idiom for array index that I'm foreach'ing over?
Tim Shoppa
with Perl data structures where I not only have to step through each element of
an array, but also must know the index into the array.
I end up writing code that looks like
for my $i (0..$#a) {
my $e = $a[$i];
# Do stuff with $i and $e here
}
That's a bit ugly, I have a numeric loop, an extra variable, that funny
(0..$#a) construct, etc. And if I have to "last" to bail out of the loop
I've lost my index and the array element that I bailed out at.
I'd rather write something like
for (@a) {
# Do stuff with $_ and some magical variable telling me the index
}
in the same way that I can
while (<>) {
# Do stuff with $_ and the line number $. here
}
Is there some magical variable like $. for array loops? Any better
idioms than what I'm currently doing?
Tim.
Lack Mr G M
|>
|> OK, I'm a former (and current!) Fortran programmer.
Ah, yes. Real FORTRAN programmer can write FORTRAN in any language :-).
|> But often I end up
|> with Perl data structures where I not only have to step through each element of
|> an array, but also must know the index into the array.
|>
|> I end up writing code that looks like
|>
|> for my $i (0..$#a) {
|> my $e = $a[$i];
|> # Do stuff with $i and $e here
|> }
|>
|> That's a bit ugly, I have a numeric loop, an extra variable, that funny
|> (0..$#a) construct, etc. And if I have to "last" to bail out of the loop
|> I've lost my index and the array element that I bailed out at.
So:
my $i;
for ($i = 0; $i < @a; $i++) {
my $e = $a[$i];
# Do stuff with $i and $e here
last if ($e > 20_000); # eg: exit statement
}
And now, after the loop, $i is still set to the value causing the exit
|> Is there some magical variable like $. for array loops? Any better
|> idioms than what I'm currently doing?
Well, possibly better is:
my $exiter; # So it is undef
for (my $i = 0; $i < @a; $i++) {
my $e = $a[$i];
# Do stuff with $i and $e here
if ($e > 20_000) { # eg: exit statement
$exiter = $i;
last;
}
}
And now, after the loop, $exiter is set to the value causing the exit
unless you reached the end of the array, in which case it is still
undefined.
--
--------- Gordon Lack --------------- gml...@ggr.co.uk ------------
This message *may* reflect my personal opinion. It is *not* intended
to reflect those of my employer, or anyone else.
Anno Siegel
Not really. The variable you want has been proposed before, right down
to the name (re-use the deprecated $#), but it isn't implemented.
A single variable would be somewhat incomplete. With nested for-loops
you'd also want a way to access the indices of enclosing loops.
If you want to keep the last index accessed, a while-loop is easier
to handle than a for-loop, because it doesn't take privacy of the
loop variable so serious:
my $i = 0;
while ( $i < @array ) {
# do something with $array[ $i];
last if bored();
$i ++; # hi Abigail
}
# use $i, it has the last value from the loop
But that's hardly an idiom, it's just a straight-forward way to do
something like that.
It may suffice to know what is left over from the array (the elements that
have *not* been processed). If so, this is a bit more perlish:
while ( @array ) {
my $element = shift @array;
# do something with $element
last if bored();
}
# now @array is what the loop left over
If you happen to know the original number of elements in @array,
"$original_length - @array" is the last index used.
I say this is "more perlish" because it uses the array as a unit. In
Fortran, an array is just a declaration, the only things you can actually
do something with are array elements, and the only way to access them is
through an index.
Perl can manipulate arrays as a whole, and doing that makes better
use of its high-level features. Once you get accustomed to this style,
you'll find that you rarely want to loop over an index. You loop over
array elements directly, and in fact map and grep do much of the looping.
If you actually need random access to elements, more often than not
the right data structure is a hash and not an array (even if the indices
happen to be numbers). With hashes, indexed access, and hence loops
over hash keys, are more frequent than with arrays, though "each" and
"values" offer alternatives.
Anno
Ben Morrow
anno...@lublin.zrz.tu-berlin.de (Anno Siegel) wrote:
> my $i = 0;
> while ( $i < @array ) {
> # do something with $array[ $i];
> last if bored();
> $i ++; # hi Abigail
I haven't been here long enough to get the 'hi Abigail', but surely
that should be in a continue block so you can 'next'?
Also, I would be more inclined to code this as
my $i = 0;
for (@array) {
# do something with $i and $_;
} continue { $i++ }
or, as you say, completely restructure the code so I didn't need to
know what $i was at all :).
Ben
--
Like all men in Babylon I have been a proconsul; like all, a slave ... During
one lunar year, I have been declared invisible; I shrieked and was not heard,
I stole my bread and was not decapitated.
~ b...@morrow.me.uk ~ Jorge Luis Borges, 'The Babylon Lottery'
Tim Shoppa
>Perl can manipulate arrays as a whole, and doing that makes better
>use of its high-level features. Once you get accustomed to this style,
>you'll find that you rarely want to loop over an index. You loop over
>array elements directly, and in fact map and grep do much of the looping.
>
>If you actually need random access to elements, more often than not
>the right data structure is a hash and not an array (even if the indices
>happen to be numbers). With hashes, indexed access, and hence loops
>over hash keys, are more frequent than with arrays, though "each" and
>"values" offer alternatives.
I agree, hashes are great, hashes are wonderful, I love hashes, but
sometimes the data really is an ordered list.
I should add that the reason that I want to know the index of the
current element is to access the same element number in another
array. (Things like a list of x coordinates in a time series and
y coordinates in a time series and the time value of each x-y
coordinates). Given this one-to-one mapping between multiple arrays, it's
probably best to make one object (possibly hash-based object-oriented
stuff) which contains x,y, and time for each point. But it seems
silly to me to go through the whole object paradigm for a simple
ten-line program, and at the same time it seems a little awkward
that the hypothetical $# doesn't exist. There are lots of ways to
make workable programs, it's just that none of them have the
simplicity and elegance that I expect out of good modern Perl
that I'm writing :-)
If the program was bigger, I'd go the full object-oriented route
with modules etc., but it seems silly to do this for such a tiny
quick little thing.
Tim.
Uri Guttman
TS> I should add that the reason that I want to know the index of the
TS> current element is to access the same element number in another
TS> array. (Things like a list of x coordinates in a time series and
TS> y coordinates in a time series and the time value of each x-y
TS> coordinates). Given this one-to-one mapping between multiple
TS> arrays, it's probably best to make one object (possibly hash-based
TS> object-oriented stuff) which contains x,y, and time for each
TS> point. But it seems silly to me to go through the whole object
TS> paradigm for a simple ten-line program, and at the same time it
TS> seems a little awkward that the hypothetical $# doesn't exist.
TS> There are lots of ways to make workable programs, it's just that
TS> none of them have the simplicity and elegance that I expect out of
TS> good modern Perl that I'm writing :-)
who says you need objects for that? you need proper perl data
structures. you really have to stop thinking in fortran!! :)
perl data structures use references which are not the same as
objects. to do a 1-1 mapping of two arrays is simple without
indexes. depending on where the data cam from you can just create a
array of arrays ( [ x, y ] coordinates ) or even add the time value as
the third array element. or you could do a simple hash like:
{ x => 1.2,
y => 3.4,
time => 12335,
}
and have an array or hash of those (not sure what the hash key would
be).
TS> If the program was bigger, I'd go the full object-oriented route
TS> with modules etc., but it seems silly to do this for such a tiny
TS> quick little thing.
perl works fine with or without objects. get your mind out of that
fortran gutter where all you have are individual arrays that can only be
linked by their indexes. that is such a poor design and paradigm.
read more about perl data structures in perllol and perldsc.
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Tim Shoppa
>perl data structures use references which are not the same as
>objects. to do a 1-1 mapping of two arrays is simple without
>indexes. depending on where the data cam from you can just create a
>array of arrays ( [ x, y ] coordinates ) or even add the time value as
>the third array element. or you could do a simple hash like:
>
> { x => 1.2,
> y => 3.4,
> time => 12335,
> }
>
>and have an array or hash of those (not sure what the hash key would
>be).
All those are workable but IMHO a bit ugly compared to creating a
"point" object that has x,y, and time methods. Your last suggestion
comes close but I don't like all those curly brackets (again, my
personal taste).
I did discover Class::MethodMaker which is somewhat elegant for
this sort of stuff.
> TS> If the program was bigger, I'd go the full object-oriented route
> TS> with modules etc., but it seems silly to do this for such a tiny
> TS> quick little thing.
>
>perl works fine with or without objects. get your mind out of that
>fortran gutter where all you have are individual arrays that can only be
>linked by their indexes. that is such a poor design and paradigm.
But it's where my mind goes for any quick-and-dirty program.
For big programs I'm quite used to the object-oriented approach...
but then I find that many CPAN modules still insist on, for example,
arrays ordered the "wrong" way (e.g. GD::Graph), so I'm forced
to take my elegant objects and break them down to a bunch of arrays
("the Fortran gutter").
I think more use of Class::MethodMaker will satisfy my desire for
elegance even when quick-and-dirty. And maybe I ought to just not
use CPAN modules from the Fortran Gutter.
Tim.
Anno Siegel
>
> anno...@lublin.zrz.tu-berlin.de (Anno Siegel) wrote:
> > my $i = 0;
> > while ( $i < @array ) {
> > # do something with $array[ $i];
> > last if bored();
> > $i ++; # hi Abigail
>
> I haven't been here long enough to get the 'hi Abigail', but surely
Oh, that's all about a blank, the one in front of "++". Abigail endorses
that style, but not everyone follows :)
> that should be in a continue block so you can 'next'?
>
> Also, I would be more inclined to code this as
>
> my $i = 0;
> for (@array) {
> # do something with $i and $_;
> } continue { $i++ }
Sure, that's more robust. I was being sketchy.
> or, as you say, completely restructure the code so I didn't need to
> know what $i was at all :).
As we have learned (news-propagation allowing), the purpose is access
to two (or more) parallel arrays. Perl isn't particularly good at that,
though no worse than comparable languages, it just isn't needed all
that much.
If you can't avoid parallel lists, I see something like
for ( map [ $_, shift @yy], @xx ) {
my ( $x, $y) = @$_;
print "x: $x, y: $y\n";
# here we go
}
which is slightly obscure and partially destructive. Maybe an indexed
approach is okay for a ten-liner.
Anno
Anno Siegel
You don't need objects just because you want an advanced data structure
in Perl. Usually it is possible to build a list of data points (triplets,
in your case) right from the input.
If, for some reason, the data is given in individual arrays, there are
many ways to pre-process them into a list of triplets. I have given an
example in another article not far from here in this thread.
The main loop would look like (untested):
for ( @data_points ) { # @data_points built elsewhere
my ( $x, $y, $t) = @{ $_}; # $_ is an array(ref) of three elements
# do things with $x, $y, $t
}
Hey, it doesn't even use a hash!
> If the program was bigger, I'd go the full object-oriented route
> with modules etc., but it seems silly to do this for such a tiny
> quick little thing.
Well, that's one of the beauties of Perl that you can often use just
enough of it to fit your needs. In this case, an array-ref neatly
encapsulates your data. This is just an alternative to Uri's hashes-used-
as-records.
Anno
Uri Guttman
>> { x => 1.2,
>> y => 3.4,
>> time => 12335,
>> }
>>
>> and have an array or hash of those (not sure what the hash key would
>> be).
TS> All those are workable but IMHO a bit ugly compared to creating a
TS> "point" object that has x,y, and time methods. Your last suggestion
TS> comes close but I don't like all those curly brackets (again, my
TS> personal taste).
but you don't speak perl so you taste is not relevent. even with objects
you need to understand perl refs.
TS> I did discover Class::MethodMaker which is somewhat elegant for
TS> this sort of stuff.
overkill. you just said you didn't want to go OO for this. make up your
mind. and you still need to learn refs.
TS> If the program was bigger, I'd go the full object-oriented route
TS> with modules etc., but it seems silly to do this for such a tiny
TS> quick little thing.
that makes no sense at all.
>> perl works fine with or without objects. get your mind out of that
>> fortran gutter where all you have are individual arrays that can only be
>> linked by their indexes. that is such a poor design and paradigm.
TS> But it's where my mind goes for any quick-and-dirty program.
if you want to get better at perl, then you should stop thinking in
fortran.
TS> For big programs I'm quite used to the object-oriented approach...
TS> but then I find that many CPAN modules still insist on, for example,
TS> arrays ordered the "wrong" way (e.g. GD::Graph), so I'm forced
TS> to take my elegant objects and break them down to a bunch of arrays
TS> ("the Fortran gutter").
huh?
TS> I think more use of Class::MethodMaker will satisfy my desire for
TS> elegance even when quick-and-dirty. And maybe I ought to just not
TS> use CPAN modules from the Fortran Gutter.
huh?
Tore Aursand
> Is there some magical variable like $. for array loops?
No. You say that you've been programming Fortran, and you're saying - at
the same time - that you're too lazy to write the following code?
my $i = 0;
foreach ( @array ) {
$_ . ' at position ' . $i . "\n";
$i++;
}
Crazy. :-)
--
Tore Aursand <to...@aursand.no>
"Out of missiles. Out of bullets. Down to harsh language." -- Unknown
Brad Baxter
> If you can't avoid parallel lists, I see something like
>
> for ( map [ $_, shift @yy], @xx ) {
> my ( $x, $y) = @$_;
> print "x: $x, y: $y\n";
> # here we go
> }
>
> which is slightly obscure and partially destructive. Maybe an indexed
> approach is okay for a ten-liner.
Here's one non-destructive version:
my %h;
@h{@xx}=@yy;
for ( map [ $_, $h{$_}], @xx ) {
my ( $x, $y) = @$_;
print "x: $x, y: $y\n";
}
Here's another. :-)
{{
my $i=0;
sub rewind{$i=0}
sub eAch(\@\@){$i>$#{$_[0]}&&$i>$#{$_[1]}?():($_[0][$i],$_[1][$i ++])}
}}
while( my( $x, $y ) = eAch( @xx, @yy ) ) {
print "x: $x, y: $y\n";
}
Regards,
Brad
Michele Dondi
<use...@morrow.me.uk> wrote:
>> $i ++; # hi Abigail
^
>I haven't been here long enough to get the 'hi Abigail', but surely
>that should be in a continue block so you can 'next'?
I *think* it is because of that space. And I can't believe it: it...
it really works!
Michele
--
# This prints: Just another Perl hacker,
seek DATA,15,0 and print q... <DATA>;
__END__
Bernard El-Hagin
news:36evsvsojg2b2riqr...@4ax.com:
> On Thu, 4 Dec 2003 19:27:00 +0000 (UTC), Ben Morrow
> <use...@morrow.me.uk> wrote:
>
>>> $i ++; # hi Abigail
> ^
>
>>I haven't been here long enough to get the 'hi Abigail', but surely
>>that should be in a continue block so you can 'next'?
>
> I *think* it is because of that space. And I can't believe it: it...
> it really works!
What's so unbelievable about it?
--
Cheers,
Bernard
Tassilo v. Parseval
> On Thu, 4 Dec 2003 19:27:00 +0000 (UTC), Ben Morrow
><use...@morrow.me.uk> wrote:
>
>>> $i ++; # hi Abigail
> ^
>
>>I haven't been here long enough to get the 'hi Abigail', but surely
>>that should be in a continue block so you can 'next'?
>
> I *think* it is because of that space. And I can't believe it: it...
> it really works!
Well, you can do funny things in Perl, particularly with whitespaces:
ethan@ethan:~$ perl
$
# comment
bla
= 5
;
print $bla;
__END__
5
As I recall, Abigail occasionally uses such tricks in an imaginative way
in his signatures.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
Anno Siegel
> On Thu, 4 Dec 2003, Anno Siegel wrote:
> > If you can't avoid parallel lists, I see something like
> >
> > for ( map [ $_, shift @yy], @xx ) {
> > my ( $x, $y) = @$_;
> > print "x: $x, y: $y\n";
> > # here we go
> > }
> >
> > which is slightly obscure and partially destructive. Maybe an indexed
> > approach is okay for a ten-liner.
>
> Here's one non-destructive version:
>
> my %h;
> @h{@xx}=@yy;
> for ( map [ $_, $h{$_}], @xx ) {
> my ( $x, $y) = @$_;
> print "x: $x, y: $y\n";
> }
No. That will generally fail when the elements in @xx aren't unique.
> Here's another. :-)
>
> {{
> my $i=0;
> sub rewind{$i=0}
> sub eAch(\@\@){$i>$#{$_[0]}&&$i>$#{$_[1]}?():($_[0][$i],$_[1][$i ++])}
> }}
Oh, the double-brace convention. I'm feeling flattered :)
> while( my( $x, $y ) = eAch( @xx, @yy ) ) {
> print "x: $x, y: $y\n";
> }
Another variation of the each-for-lists theme, with a nice use of
prototypes. If we had a prototype for "arbitrarily many of \@", this
could be generalized to a step-by-step transposition routine for any
number of parallel arrays.
Anno
Tim Shoppa
> On Thu, 04 Dec 2003 07:42:42 -0800, Tim Shoppa wrote:
> > Is there some magical variable like $. for array loops?
>
> No. You say that you've been programming Fortran, and you're saying - at
> the same time - that you're too lazy to write the following code?
>
> my $i = 0;
> foreach ( @array ) {
> $_ . ' at position ' . $i . "\n";
> $i++;
> }
>
> Crazy. :-)
Creating a brand new variable with scope outside the loop body and no
use outside the body, which I then have to increment each time
around the loop (and remember not to "next" before the code that increments
it), when obviously the computer internally knows the index of the
element it's working on, isn't crazy?
And while everyone is telling me that I'm some thick-headed Fortran
programmer who doesn't know how to use Perl data structures, I
generally have to generate arrays in these forms because
other Perl modules from CPAN insist on non-structured arrays of
X-Y data. (Specifically, GD::Graph and Perl/Tk, but they take their
arrays in different orders... GD::Graph wants a list of x's and a list of
y's, while Perl/Tk generally wants x0-y0-x1-y1-x2-y2-etc.). I did
learn some less-than-elegant idioms for converting to/from these forms, though.
Tim.
Brad Baxter
> Creating a brand new variable with scope outside the loop body and no
> use outside the body, which I then have to increment each time
> around the loop (and remember not to "next" before the code that increments
> it), when obviously the computer internally knows the index of the
> element it's working on, isn't crazy?
Okay, for what it's worth, here's my attempt at cleverness. No, it's not
exactly what you asked for ...
{{
my $i=0;
sub rewind{$i=0}
sub it(\@){$i>$#{$_[0]}?():($i+0,$_[0][$i++])}
}}
while( my( $i, $it ) = it( @array ) ) {
print "i: $i, it: $it\n";
}
Regards,
Brad
Michele Dondi
<b...@ginger.libs.uga.edu> wrote:
>Here's another. :-)
>
>{{
^^
>my $i=0;
>sub rewind{$i=0}
>sub eAch(\@\@){$i>$#{$_[0]}&&$i>$#{$_[1]}?():($_[0][$i],$_[1][$i ++])}
>}}
^^
Why double braces?!? Ah! Nice JAPH btw...
Michele
--
$\=q.,.,$_=q.print' ,\g,,( w,a'c'e'h,,map{$_-=qif/g/;chr
}107..q[..117,q)[map+hex,split//,join' ,2B,, w$ECDF078D3'
F9'5F3014$,$,];];$\.=$/,s,q,32,g,s,g,112,g,y,' , q,,eval;
Anno Siegel
Drawing in the OPs intentions, this would be required to work for more
than one array. We can't make the number of arrays entirely arbitrary
due to limitations in prototypes (or can we?), but this works for up
to five arrays:
BEGIN {{
my $i = -1;
sub rewind { $i = -1 }
sub them (;\@\@\@\@\@) {
$i++; # increment early, so we can return a valid index
return if $i >= @{ $_[ 0]};
( $i, map $_->[ $i], @_);
}
}}
while ( my ( $i, $x, $y, $t) = them( @xx, @yy, @tt) ) {
print "i: $i, x: $x, y: $y, t: $t\n";
}
Of course this is utterly fragile when applied to more than one set
of arrays, but for the given purpose it would do.
Anno
Ben Morrow
anno...@lublin.zrz.tu-berlin.de (Anno Siegel) wrote:
> BEGIN {{
> my $i = -1;
> sub rewind { $i = -1 }
>
> sub them (;\@\@\@\@\@) {
> $i++; # increment early, so we can return a valid index
> return if $i >= @{ $_[ 0]};
> ( $i, map $_->[ $i], @_);
> }
> }}
>
> while ( my ( $i, $x, $y, $t) = them( @xx, @yy, @tt) ) {
> print "i: $i, x: $x, y: $y, t: $t\n";
> }
>
> Of course this is utterly fragile when applied to more than one set
> of arrays, but for the given purpose it would do.
To remove some of the fragility (untested):
BEGIN {{
my %i;
sub rewind (;\@\@\@\@\@) { $i{join "", @_} = -1 }
sub them (;\@\@\@\@\@) {
my $set = join "", @_;
$i{$set} = -1 unless defined $i{$set}; # $i{$set} //= -1;
$i{$set}++;
rewind(@_), return if grep { $i{$set} >= @$_ } @_;
# I'm not sure what we want here... 'if @_ == grep ...' may be better.
( $i{$set}, map $_->[$i{$set}], @_);
}
}}
Ben
--
For the last month, a large number of PSNs in the Arpa[Inter-]net have been
reporting symptoms of congestion ... These reports have been accompanied by an
increasing number of user complaints ... As of June,... the Arpanet contained
47 nodes and 63 links. [ftp://rtfm.mit.edu/pub/arpaprob.txt] * b...@morrow.me.uk
Brad Baxter
> On Thu, 4 Dec 2003 23:10:18 -0500, Brad Baxter
> <b...@ginger.libs.uga.edu> wrote:
>
> >{{
> ^^
> >my $i=0;
> >sub rewind{$i=0}
> >sub eAch(\@\@){$i>$#{$_[0]}&&$i>$#{$_[1]}?():($_[0][$i],$_[1][$i ++])}
> >}}
> ^^
>
> Why double braces?!? Ah! Nice JAPH btw...
Thanks. :-) The double braces are just a nod to Anno's post on Nov 22,
re: top level blocks and indentation.
Regards,
Brad
Brad Baxter
> Brad Baxter <b...@ginger.libs.uga.edu> wrote in comp.lang.perl.misc:
> > Here's one non-destructive version:
> >
> > my %h;
> > @h{@xx}=@yy;
> > for ( map [ $_, $h{$_}], @xx ) {
> > my ( $x, $y) = @$_;
> > print "x: $x, y: $y\n";
> > }
>
> No. That will generally fail when the elements in @xx aren't unique.
Too true. I was telling myself, "but that requires an extra copy of
everything", and I missed the real reason it's wrong.
> > Here's another. :-)
> >
> > {{
> > my $i=0;
> > sub rewind{$i=0}
> > sub eAch(\@\@){$i>$#{$_[0]}&&$i>$#{$_[1]}?():($_[0][$i],$_[1][$i ++])}
> > }}
>
> Oh, the double-brace convention. I'm feeling flattered :)
Just wanted to show I wasn't sleeping in class. :-) An aspect of that
convention that appeals particularly is, I think, that it somewhat
emulates file-scoping traits in your module example. That is, the
lexicals in each package would not be seen in the other packages. Yes, a
single brace would work, too, but being double is an instant clue.
> > while( my( $x, $y ) = eAch( @xx, @yy ) ) {
> > print "x: $x, y: $y\n";
> > }
>
> Another variation of the each-for-lists theme, with a nice use of
> prototypes. If we had a prototype for "arbitrarily many of \@", this
> could be generalized to a step-by-step transposition routine for any
> number of parallel arrays.
Yes. I'm imagining tricks using eval, overload, Hairy? But inspiration
is low.
Regards,
Brad
Anno Siegel
> > BEGIN {{
> > my $i = -1;
> > sub rewind { $i = -1 }
> >
> > sub them (;\@\@\@\@\@) {
> > $i++; # increment early, so we can return a valid index
> > return if $i >= @{ $_[ 0]};
> > ( $i, map $_->[ $i], @_);
> > }
> > }}
> >
> > while ( my ( $i, $x, $y, $t) = them( @xx, @yy, @tt) ) {
> > print "i: $i, x: $x, y: $y, t: $t\n";
> > }
> >
> > Of course this is utterly fragile when applied to more than one set
> > of arrays, but for the given purpose it would do.
>
> To remove some of the fragility (untested):
Runs here.
> BEGIN {{
> my %i;
>
> sub rewind (;\@\@\@\@\@) { $i{join "", @_} = -1 }
>
> sub them (;\@\@\@\@\@) {
> my $set = join "", @_;
> $i{$set} = -1 unless defined $i{$set}; # $i{$set} //= -1;
> $i{$set}++;
> rewind(@_), return if grep { $i{$set} >= @$_ } @_;
> # I'm not sure what we want here... 'if @_ == grep ...' may be better.
So far, I have taken the first array to be the measure of all. Oh, so the
prototype should be (\@;\@...), a bug. Yours take the maximum or the
minimum length of all arrays offered, which is more thorough. There may
be other useful strategies.
> ( $i{$set}, map $_->[$i{$set}], @_);
> }
> }}
The code can be simplified a bit with re-introduction of a plain scalar $i.
In particular, we can lose the pesky initialization to -1.
my %i;
sub rewind (;\@\@\@\@\@) { delete $i{ join "", @_} }
sub them (;\@\@\@\@\@) {
my $i = $i{ join "", @_} ++; # increment for next time, use current
rewind(@_), return if grep { $i >= @$_ } @_;
( $i, map $_->[$i], @_);
}
I think only a purist would complain about the use of $i and %i here.
Anno
Michele Dondi
<bernard.el-ha...@lido-tech.net> wrote:
>Michele Dondi <bik....@tiscalinet.it> wrote in
>news:36evsvsojg2b2riqr...@4ax.com:
>>
>>>> $i ++; # hi Abigail
>> ^
[snip]
>> I *think* it is because of that space. And I can't believe it: it...
>> it really works!
>
>What's so unbelievable about it?
Hmmm... maybe that I didn't think it was possible?!?
On 5 Dec 2003 11:02:11 GMT, "Tassilo v. Parseval"
<tassilo....@rwth-aachen.de> wrote:
>Well, you can do funny things in Perl, particularly with whitespaces:
>
> ethan@ethan:~$ perl
> $
> # comment
> bla
>
>
> = 5
> ;
>
> print $bla;
> __END__
> 5
I didn't expect this to be possible either. Funny!
The trick doesn't always work, anyway:
# perl -le 'print $i ++ for 1..3'
syntax error at -e line 1, near "++ for "
Execution of -e aborted due to compilation errors.
# perl -le 'print($i ++) for 1..3'
syntax error at -e line 1, near "++ for "
Execution of -e aborted due to compilation errors.
# perl -le 'print +($i ++) for 1..3'
0
1
2
# perl -le 'print do{$i ++} for 1..3'
0
1
2
Could you please be so kind and explain me what perl understands in
the respective cases? In particular I am not puzzled by the fact that
the first one fails and the last one succeeds, but I can't understand
why the second one does not.
As a side (minor) note, by the examples above one sees that even if
the postfix form of the auto increment operator should *increment* the
variable after returning its value, in practice it *modifies* its
value before returning it:
# perl -le "print $i; print $i++"
0
I checked perldoc perlop and read the magic bit about the
auto-increment operator with strings, but I don't think it applies
here. Also, it doesn't treat explicitly of the case of undefined
variables.
Ben Morrow
Michele Dondi <bik....@tiscalinet.it> wrote:
> >What's so unbelievable about it?
>
> Hmmm... maybe that I didn't think it was possible?!?
As a general rule, Perl *completely* ignores whitespace. The only
exception I know of is when you have two sequences of \w next to other
which should be interpreted as separate identifiers: ws is required
then.
> On 5 Dec 2003 11:02:11 GMT, "Tassilo v. Parseval"
> <tassilo....@rwth-aachen.de> wrote:
>
> >Well, you can do funny things in Perl, particularly with whitespaces:
> >
> > ethan@ethan:~$ perl
> > $
> > # comment
> > bla
> >
> >
> > = 5
> > ;
> >
> > print $bla;
> > __END__
> > 5
>
> I didn't expect this to be possible either. Funny!
Comments are whitespace.
> The trick doesn't always work, anyway:
>
> # perl -le 'print $i ++ for 1..3'
> syntax error at -e line 1, near "++ for "
> Execution of -e aborted due to compilation errors.
perl -le'print STDOUT $i ++ for 1..3'
> # perl -le 'print($i ++) for 1..3'
> syntax error at -e line 1, near "++ for "
> Execution of -e aborted due to compilation errors.
perl -le'print (STDOUT $i ++) for 1..3'
perl -le'print STDOUT ($i ++) for 1..3'
The problem here is that the rule for parsing an indirect object is
very greedy: as soon as it has something that could be interpreted as
one, it grabs it. So 'print $i ++' is interpreted trying to print '++'
to the filehandle '$i': the '++' is then a syntax error. Adding the
brackets makes no difference, *even* if they have whitespace before
them (I keep getting bitten by this :).
> # perl -le 'print +($i ++) for 1..3'
perl -le'print +$i ++ for 1..3'
> # perl -le 'print do{$i ++} for 1..3'
An indirect object cannot start with '+', or with 'do', so there's no
problem here. See perlobj/"Indirect Object Syntax".
> Could you please be so kind and explain me what perl understands in
> the respective cases? In particular I am not puzzled by the fact that
> the first one fails and the last one succeeds, but I can't understand
> why the second one does not.
I was initially puzzled as to why *any* of them failed...
> As a side (minor) note, by the examples above one sees that even if
> the postfix form of the auto increment operator should *increment* the
> variable after returning its value, in practice it *modifies* its
> value before returning it:
>
> # perl -le "print $i; print $i++"
>
> 0
>
> Also, it doesn't treat explicitly of the case of undefined
> variables.
Err...
| "undef" is always treated as numeric, and in particular is changed
| to 0 before incrementing (so that a post-increment of an undef value
| will return 0 rather than "undef").
This is from perlop in 5.8.2.
Tassilo v. Parseval
> Michele Dondi <bik....@tiscalinet.it> wrote:
>> >What's so unbelievable about it?
>>
>> Hmmm... maybe that I didn't think it was possible?!?
>
> As a general rule, Perl *completely* ignores whitespace. The only
> exception I know of is when you have two sequences of \w next to other
> which should be interpreted as separate identifiers: ws is required
> then.
It's a little more complicated in fact. Here's one that Abigail
simply adores:
ethan@ethan:~$ perl -lw
print(1+2)*3;
Useless use of multiplication (*) in void context at - line 1.
3
ethan@ethan:~$ perl -lw
print (1+2)*3;
print (...) interpreted as function at - line 1.
Useless use of multiplication (*) in void context at - line 1.
3
The additional whitespace in the second example will trigger an
additional warning.
Darin McBride
> In article <x7u14gz...@mail.sysarch.com>, Uri Guttman says...
>>perl data structures use references which are not the same as
>>objects. to do a 1-1 mapping of two arrays is simple without
>>indexes. depending on where the data cam from you can just create a
>>array of arrays ( [ x, y ] coordinates ) or even add the time value as
>>the third array element. or you could do a simple hash like:
>>
>>{ x => 1.2,
>>y => 3.4,
>>time => 12335,
>>}
>>
>>and have an array or hash of those (not sure what the hash key would
>>be).
>
> All those are workable but IMHO a bit ugly compared to creating a
As I once heard, you can write Fortran in any language. The point is:
don't. The hash above is exactly what one should do in perl. If you
were in C, I would say put everything in a struct, and have an array of
those. In Perl, put everything in a hash, and have an array of refs to
those.
> "point" object that has x,y, and time methods. Your last suggestion
> comes close but I don't like all those curly brackets (again, my
> personal taste).
Sorry - if you don't like braces, perl is not for you. Perl is all
about simple, short, if someone obtuse, ways of saying things. Most of
the punctuation has meaning, and if you don't like it, you'll need to
find another language. Perhaps REXX may be more to your liking.
>> TS> If the program was bigger, I'd go the full object-oriented route
>> TS> with modules etc., but it seems silly to do this for such a tiny
>> TS> quick little thing.
>>
>>perl works fine with or without objects. get your mind out of that
>>fortran gutter where all you have are individual arrays that can only be
>>linked by their indexes. that is such a poor design and paradigm.
>
> But it's where my mind goes for any quick-and-dirty program.
In other words, you still are thinking Fortran rather than thinking
perl. To be honest, very few languages would encourage that type of
programming, so if you want to spread out past Fortran, I would
encourage you to embrace it.
Brad Baxter
> The code can be simplified a bit with re-introduction of a plain scalar $i.
> In particular, we can lose the pesky initialization to -1.
>
> my %i;
>
> sub rewind (;\@\@\@\@\@) { delete $i{ join "", @_} }
>
> sub them (;\@\@\@\@\@) {
> my $i = $i{ join "", @_} ++; # increment for next time, use current
> rewind(@_), return if grep { $i >= @$_ } @_;
> ( $i, map $_->[$i], @_);
> }
>
You guys are something else. It only just occurred to me that you've
provided for the following to work:
my @aa = qw( a b c d e f );
my @nn = qw( 1 2 3 4 );
my @xx = qw( x y z );
print them( @aa, @nn, @xx ), "\n";
print these( \@aa, \@nn, \@xx ), "\n";
print them( @aa, @nn, @xx ), "\n";
sub these {
my( $q, $w, $e ) = @_;
them( @$q, @$w, @$e );
}
Nice. I wonder if it would be useful to have a query for the position.
(I had to fiddle with the order of things ...)
{{
my %i;
sub rewind (;\@\@\@\@\@) { delete $i{ join "", @_} }
sub saw (;\@\@\@\@\@) { ($i{ join "", @_}||0) - 1 }
sub them (;\@\@\@\@\@) {
my $s = join "", @_;
my $i = $i{ $s }||0;
rewind(@_), return if grep { $i >= @$_ } @_;
$i{ $s } ++;
( $i, map $_->[$i], @_);
}
}}
my @aa = qw( a b c d e f );
my @nn = qw( 1 2 3 4 );
my @xx = qw( x y z );
print "saw: ", saw( @aa, @nn, @xx ), "\n";
while( my ( $i, $a, $n, $x ) = them( @aa, @nn, @xx ) ) {
print "$i, $a, $n, $x\n";
print "saw: ", saw( @aa, @nn, @xx ), "\n";
}
print "saw: ", saw( @aa, @nn, @xx ), "\n";
_____
saw: -1
0, a, 1, x
saw: 0
1, b, 2, y
saw: 1
2, c, 3, z
saw: 2
saw: 2
Regards,
Brad
Brad Baxter
> {{
> my %i;
>
> sub rewind (;\@\@\@\@\@) { delete $i{ join "", @_} }
>
> sub saw (;\@\@\@\@\@) { ($i{ join "", @_}||0) - 1 }
>
> sub them (;\@\@\@\@\@) {
> my $s = join "", @_;
> my $i = $i{ $s }||0;
> rewind(@_), return if grep { $i >= @$_ } @_;
> $i{ $s } ++;
> ( $i, map $_->[$i], @_);
> }
> }}
Pardon the autofollowup. That rewind(@_) isn't quite right. Here's a
reason for using '&'.
sub them (;\@\@\@\@\@) {
my $s = join "", @_;
my $i = $i{ $s }||0;
&rewind, return if grep { $i >= @$_ } @_;
$i{ $s } ++;
( $i, map $_->[$i], @_);
}
Regards,
Brad
Brad Baxter
> Ben Morrow <use...@morrow.me.uk> wrote in comp.lang.perl.misc:
> > # I'm not sure what we want here... 'if @_ == grep ...' may be better.
>
> So far, I have taken the first array to be the measure of all. Oh, so the
> prototype should be (\@;\@...), a bug. Yours take the maximum or the
> minimum length of all arrays offered, which is more thorough. There may
> be other useful strategies.
Regarding other strategies, I was thinking of an option to "go out of
bounds", i.e., to take the maximum length in the set of arrays.
Assigning to the "goob" routine both chooses this option and sets the
value to return when you're out of bounds., e.g.
goob( @aa, @bb ) = ''; # or perhaps 0 or even undef
Do you see a better way to do that?
my %i;
my %goob; # parallel hashes, no less
sub goob (;\@\@\@\@\@) : lvalue { $goob{ join "", @_ } }
sub start (;\@\@\@\@\@) : lvalue { $i{ join "", @_} }
sub saw (;\@\@\@\@\@) { ($i{ join "", @_}||0) - 1 }
sub rewind (;\@\@\@\@\@) { delete $i{ join "", @_} }
sub them (;\@\@\@\@\@) {
my $set = join "", @_;
my $i = $i{ $set } ++; # increment for next time, use current
if( exists $goob{ $set } ) {
&rewind, return unless grep { $i < @$_ } @_;
return ( $i, map { $i < @$_ ? $_->[$i] : $goob{ $set } } @_);
}
&rewind, return if grep { $i >= @$_ } @_;
( $i, map $_->[$i], @_);
}
Regards,
Brad
Abigail
September MCMXCIII in <URL:news:bqsmhg$lso$1...@nets3.rz.RWTH-Aachen.DE>:
&& Also sprach Ben Morrow:
&&
&& > Michele Dondi <bik....@tiscalinet.it> wrote:
&& >> >What's so unbelievable about it?
&& >>
&& >> Hmmm... maybe that I didn't think it was possible?!?
&& >
&& > As a general rule, Perl *completely* ignores whitespace. The only
&& > exception I know of is when you have two sequences of \w next to other
&& > which should be interpreted as separate identifiers: ws is required
&& > then.
&&
&& It's a little more complicated in fact. Here's one that Abigail
&& simply adores:
&&
&& ethan@ethan:~$ perl -lw
&& print(1+2)*3;
&& Useless use of multiplication (*) in void context at - line 1.
&& 3
&& ethan@ethan:~$ perl -lw
&& print (1+2)*3;
&& print (...) interpreted as function at - line 1.
&& Useless use of multiplication (*) in void context at - line 1.
&& 3
&&
&& The additional whitespace in the second example will trigger an
&& additional warning.
Not in my perl!
$ perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 2) configuration:
...
Locally applied patches:
defined-or
no print (...) warning
stacked file ops
Abigail
--
sub _ {$_ = shift and y/b-yB-Y/a-yB-Y/ xor !@ _?
exit print :
print and push @_ => shift and goto &{(caller (0)) [3]}}
split // => "KsvQtbuf fbsodpmu\ni flsI " xor & _
Abigail
MCMXCIII in <URL:news:36evsvsojg2b2riqr...@4ax.com>:
}} On Thu, 4 Dec 2003 19:27:00 +0000 (UTC), Ben Morrow
}} <use...@morrow.me.uk> wrote:
}}
}} >> $i ++; # hi Abigail
}} ^
}}
}} >I haven't been here long enough to get the 'hi Abigail', but surely
}} >that should be in a continue block so you can 'next'?
}}
}} I *think* it is because of that space. And I can't believe it: it...
}} it really works!
Well, yes, of course. This is after all Perl5, which like every other
main stream language I know about allows optional whitespace between
tokens. The whitespace isn't significant.
Unlike Perl6, which just throws out 50 years of programming language
design out of the window, passes Python on the wrong side and makes
whitespace significant in new painful and revolting ways.
Abigail
--
perl -wle'print"Кхуф бопфиет Ретм Ибглет"^"\x80"x24'
Iain Chalmers
anno...@lublin.zrz.tu-berlin.de (Anno Siegel) wrote:
> I think only a purist would complain about the use of $i and %i here.
But remember, you're helping out a _Fortran_ guy here... $i as an array
index, sure - but as a *hash* name???
:-)
big
--
'When I first met Katho, she had a meat cleaver in one hand and
half a sheep in the other. "Come in", she says, "Hammo's not here.
I hope you like meat.' Sharkey in aus.moto
Michele Dondi
<use...@morrow.me.uk> wrote:
>Err...
>
>| "undef" is always treated as numeric, and in particular is changed
>| to 0 before incrementing (so that a post-increment of an undef value
>| will return 0 rather than "undef").
>
>This is from perlop in 5.8.2.
Still 5.8.0 here, and unless I've gone completely dumb, that bit is
not in perlop.
Michele Dondi
>Well, yes, of course. This is after all Perl5, which like every other
>main stream language I know about allows optional whitespace between
>tokens. The whitespace isn't significant.
>
>Unlike Perl6, which just throws out 50 years of programming language
>design out of the window, passes Python on the wrong side and makes
>whitespace significant in new painful and revolting ways.
Just out of curiosity: is this definitive or are there chances that
such "features" may be removed/changed before before Perl6 is actually
released in productive form?
Brad Baxter
Idiom for array index that I'm foreach'ing over?]
I'm considering making a new module with the tentative name Array::Each.
A draft is available here:
http://www.vitabrevis.ws/perl/modules/Array/Each.pm
http://www.vitabrevis.ws/perl/modules/Array/Each.pod.html
It's incomplete, but I want to discuss the idea before proceeding further.
1. Is Array::Each acceptable? Perhaps Array::Parallel, or
Array::Iteration?
2. Are the subroutine names acceptable? In particular, I expect negative
reactions to each(), since it would clobber each( %hash ), so alternative
suggestions are welcome.
3. Is this a good approach? Are all those options needed? Does it matter
that it doesn't return lvalues like foreach ( @array )?
4. Should someone else do this/Has someone else done this? I did study
the CPAN module list and didn't find a close match. That I missed one
would not surprise me.
5. I imagine sometime adding an OO interface along these lines:
my $set = Array::Each->new( @x, @y );
my( $i, $x, $y ) = $set->each();
Among other things, this should allow iterating over the same set of
arrays using different iterators. Should I bother?
All feedback is appreciated.
Thanks,
Brad
Abigail
MCMXCIII in <URL:news:q0sotv49cr080v9mv...@4ax.com>:
{} On 07 Dec 2003 21:56:41 GMT, Abigail <abi...@abigail.nl> wrote:
{}
{} >Well, yes, of course. This is after all Perl5, which like every other
{} >main stream language I know about allows optional whitespace between
{} >tokens. The whitespace isn't significant.
{} >
{} >Unlike Perl6, which just throws out 50 years of programming language
{} >design out of the window, passes Python on the wrong side and makes
{} >whitespace significant in new painful and revolting ways.
{}
{} Just out of curiosity: is this definitive or are there chances that
{} such "features" may be removed/changed before before Perl6 is actually
{} released in productive form?
Nothing is definitive, but Larry and Damian seem to be convinced that
the gain of saving 2 characters on an if() are worth sacrificing the
non-significance of whitespace, that I say the chances are small.
On the other hand, I'm more and more convinced that I will be retired
before Larry finishes the language specification. ;-)
Abigail
--
sub f{sprintf$_[0],$_[1],$_[2]}print f('%c%s',74,f('%c%s',117,f('%c%s',115,f(
'%c%s',116,f('%c%s',32,f('%c%s',97,f('%c%s',0x6e,f('%c%s',111,f('%c%s',116,f(
'%c%s',104,f('%c%s',0x65,f('%c%s',114,f('%c%s',32,f('%c%s',80,f('%c%s',101,f(
'%c%s',114,f('%c%s',0x6c,f('%c%s',32,f('%c%s',0x48,f('%c%s',97,f('%c%s',99,f(
'%c%s',107,f('%c%s',101,f('%c%s',114,f('%c%s',10,)))))))))))))))))))))))))
Bryan Castillo
The code below ............
use strict;
use warnings;
use Array::Each qw/them rewind/;
$|=1;
while (1) {
my @array = map{rand}(1..10);
while (my ($k,$v) = them(@array)) {
print "[$k:$v]";
last if ($k == 0);
}
print "\nnext -> ";
### rewind(@array); # would fix it
}
produces..............
next -> [1:0][2:8]
next -> [0:4]
next -> [1:4][2:0]
next -> [0:1]
next -> [1:0][2:3]
next -> [0:0]
next -> [1:9][2:9]
next -> [0:1]
next -> [1:6][2:4]
next -> [0:1]
next -> [1:0][2:7]
next -> [0:0]
I realize that this occurs, because the variable has the same
reference
even though it has completely changed. You might want to note
something
about breaking out of iteration and how you should call rewind if you
are
going to be using the same variable in a loop.
Anyway, I could see how someone might write code that leaves entries
in your %set variable which are never deleted. This might be a
problem for a daemon.
Perhaps, some type of syntax as shown below would work.....
Without keeping a global hash.......
Of course it would have to be modified to iterate over multiple
arrays.
(I like your syntax better, I just don't like the way context is
maintained.
Although I don't see any better way to do it, while keeping your
syntax.)
use strict;
use warnings;
sub on_each(&@) {
my $code = shift;
for (my $i=0; $i<=$#_; $i++) {
$code->($i, $_[$i]);
}
}
on_each {
print "Index = $_[0] and Value = $_[1]\n";
} (1..10);
I really don't like the idea of the function being named each, but
that is just my opinion.
Anno Siegel
> [This stems somewhat from discussions in the thread:
> Idiom for array index that I'm foreach'ing over?]
>
> I'm considering making a new module with the tentative name Array::Each.
>
> A draft is available here:
>
> http://www.vitabrevis.ws/perl/modules/Array/Each.pm
> http://www.vitabrevis.ws/perl/modules/Array/Each.pod.html
>
> It's incomplete, but I want to discuss the idea before proceeding further.
>
> 1. Is Array::Each acceptable? Perhaps Array::Parallel, or
> Array::Iteration?
>
> 2. Are the subroutine names acceptable? In particular, I expect negative
> reactions to each(), since it would clobber each( %hash ), so alternative
> suggestions are welcome.
>
> 3. Is this a good approach? Are all those options needed? Does it matter
> that it doesn't return lvalues like foreach ( @array )?
>
> 4. Should someone else do this/Has someone else done this? I did study
> the CPAN module list and didn't find a close match. That I missed one
> would not surprise me.
>
> 5. I imagine sometime adding an OO interface along these lines:
>
> my $set = Array::Each->new( @x, @y );
> my( $i, $x, $y ) = $set->each();
By all means, go for an OO approach. This stuff has been shouting
"object" from the moment we introduced the %i hash with its keys to
distinguish different iterators.
The user will have to create an iterator object (instead of "spontaneously"
saying "( $i, $x, $y) = each( @x, @y)"), but it will be much clearer
what's happening.
> Among other things, this should allow iterating over the same set of
> arrays using different iterators. Should I bother?
That's one of the advantages of explicit iterators.
> All feedback is appreciated.
Make each() return the index last (after the array elements) instead
of first. That way the first n values correspond to the n arrays, and
the index is easy to ignore when it isn't needed.
Anno
Eric J. Roode
Hash: SHA1
Michele Dondi <bik....@tiscalinet.it> wrote in
news:q0sotv49cr080v9mv...@4ax.com:
> On 07 Dec 2003 21:56:41 GMT, Abigail <abi...@abigail.nl> wrote:
>
>>Unlike Perl6, which just throws out 50 years of programming
language
>>design out of the window, passes Python on the wrong side and
makes
>>whitespace significant in new painful and revolting ways.
>
> Just out of curiosity: is this definitive or are there chances
that
> such "features" may be removed/changed before before Perl6 is
actually
> released in productive form?
Alas, very slim. :-( I have this nagging feeling that version 6 is
going to be the worst thing that ever happened to Perl.
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32) - WinPT 0.5.13
iD8DBQE/1w+jY96i4h5M0egRAml7AJ9tDxJsIzrhWlGO+pTdrzI3t90D7wCgpdp3
RRhonHoRGuZerY3Gue1XFzA=
=jgan
-----END PGP SIGNATURE-----
Bryan Castillo
> Brad Baxter <b...@ginger.libs.uga.edu> wrote in comp.lang.perl.misc:
> > [This stems somewhat from discussions in the thread:
> > Idiom for array index that I'm foreach'ing over?]
> >
> > I'm considering making a new module with the tentative name Array::Each.
> >
> > A draft is available here:
> >
> > http://www.vitabrevis.ws/perl/modules/Array/Each.pm
> > http://www.vitabrevis.ws/perl/modules/Array/Each.pod.html
> >
> > It's incomplete, but I want to discuss the idea before proceeding further.
> >
> > 1. Is Array::Each acceptable? Perhaps Array::Parallel, or
> > Array::Iteration?
> >
> > 2. Are the subroutine names acceptable? In particular, I expect negative
> > reactions to each(), since it would clobber each( %hash ), so alternative
> > suggestions are welcome.
> >
> > 3. Is this a good approach? Are all those options needed? Does it matter
> > that it doesn't return lvalues like foreach ( @array )?
> >
> > 4. Should someone else do this/Has someone else done this? I did study
> > the CPAN module list and didn't find a close match. That I missed one
> > would not surprise me.
> >
> > 5. I imagine sometime adding an OO interface along these lines:
> >
> > my $set = Array::Each->new( @x, @y );
> > my( $i, $x, $y ) = $set->each();
>
> By all means, go for an OO approach. This stuff has been shouting
> "object" from the moment we introduced the %i hash with its keys to
> distinguish different iterators.
>
Isn't there some type of Iterator package for perl? Why stop at arrays?
If there would be an OO approach, why not have iterators for many things.
Here is a simplified example of what Im thinking about.
It is using closures instead of full objects (for brevity);
package Iterator;
use strict;
use warnings;
# iterator over multiple arrays
sub arrays(;\@\@\@\@\@) {
my $arrays = [@_];
my $i = -1;
my $mi = -1;
foreach(@_) { $mi = $#{$_} if ($#{$_} > $mi) }
return sub {
return () if ($i >= $mi);
return (++$i, map{$_->[$i]} @{$arrays});
};
}
# iterate over multiple hashes
sub hashes(;\%\%\%\%\%) {
my $hashes = [@_];
my %keys;
map{$keys{$_}=1} keys %{$_} foreach(@_);
my @keys = keys %keys;
my $i = -1;
return sub {
return () if ($i >= $#keys);
return ($keys[++$i], map{$_->{$keys[$i]}} @{$hashes});
};
}
# iterate over 2d array
sub array2d {
my ($x,$y) = (-1,0);
my $array = ($#_ == 0 and UNIVERSAL::isa($_[0], 'ARRAY')) ? $_[0] : [@_];
my $my = $#{$array};
my $mx = ($my >= 0) ? $#{$array->[0]} : -1;
return sub {
if (++$x > $mx) { $y++; $x=0 }
return () if ($y > $my);
return ($y,$x,$array->[$y][$x]);
};
}
# Find and load dynamic iterator
sub find_iterator {
my $imod = shift;
print "imod = $imod\n";
my $imod_file = "Iterator/$imod";
$imod_file =~ s/::/\//g;
$imod_file .= ".pm";
require $imod_file;
no strict 'refs';
my $get_iter = \&{*{"Iterator::${imod}::iterator"}};
warn "not iterator found for $imod\n" and return unless($get_iter);
return $get_iter->(@_);
}
package main;
use strict;
use warnings;
no warnings 'uninitialized';
my @a = qw/ 1 2 3 4/;
my @b;
my @c = qw/6 7 8 9/;
my $iter_a = Iterator::arrays(@a,@b,@c);
while (my ($i,$v1,$v2,$v3) = $iter_a->()) {
print "[$i] ($v1,$v2,$v3)\n";
}
print "-" x 40, "\n";
my %a = (a=>1,b=>2,c=>3);
my %b = (z=>99);
my %c = (xx=>'xx',hash=>\%a);
my $iter_b = Iterator::hashes(%a, %b, %c);
while (my ($k,$v1,$v2,$v3) = $iter_b->()) {
print "[$k] ($v1,$v2,$v3)\n";
}
print "-" x 40, "\n";
my $array = [
[1,2,3],
[4,5,6],
[7,8,9]
];
my $iter_c = Iterator::array2d($array);
while (my ($y,$x,$value) = $iter_c->()) {
print "($y,$x) = ($value)\n";
}
print "-" x 40, "\n";
my $iter_d = Iterator::find_iterator('files', "*.pl");
while (my ($i, $file) = $iter_d->()) {
print "[$i] = $file\n";
}
# Iterator/files.pm
package Iterator::files;
use strict;
use warnings;
sub iterator {
my @files = sort glob(shift);
my $i = -1;
return sub {
return () if (++$i > $#files);
return ($i, $files[$i]);
};
}
return 1;
Michele Dondi
>{} >Unlike Perl6, which just throws out 50 years of programming language
>{} >design out of the window, passes Python on the wrong side and makes
>{} >whitespace significant in new painful and revolting ways.
>{}
>{} Just out of curiosity: is this definitive or are there chances that
>{} such "features" may be removed/changed before before Perl6 is actually
>{} released in productive form?
>
>Nothing is definitive, but Larry and Damian seem to be convinced that
>the gain of saving 2 characters on an if() are worth sacrificing the
>non-significance of whitespace, that I say the chances are small.
It would be nice if this behaviour could be triggered somehow, say by
means of yet another cmd line switch or a pragma...
But shouldn't Perl6 be the "community rewrite" (IIRC) of Perl? What
does the community think here?!?
On Wed, 10 Dec 2003 06:19:10 -0600, "Eric J. Roode"
<REMOVE...@comcast.net> wrote:
>Alas, very slim. :-( I have this nagging feeling that version 6 is
>going to be the worst thing that ever happened to Perl.
Well I know next to nothing about Perl6, but as a general disposition
I feel inclined to anticipate with enthusiasm any kind of innovation,
not to fear it.
Now, what I came to know in this thread is certainly something that I
completely dislike, agreeing with you both (FWIW MHO!). But I'll wait
to see the living creature...
BTW: what would be the best resource for discussing own
ideas/questions about feaures of (any future major release of Perl,
but then most definitely) Perl6? Please not that I'm talking about
(possibly) naive or generic issues, so too technical a
forum/board/whatever may not be well suited for them...
Abigail
MCMXCIII in <URL:news:nj9stvor4l728tbtc...@4ax.com>:
][ On 09 Dec 2003 21:52:10 GMT, Abigail <abi...@abigail.nl> wrote:
][
][ >{} >Unlike Perl6, which just throws out 50 years of programming language
][ >{} >design out of the window, passes Python on the wrong side and makes
][ >{} >whitespace significant in new painful and revolting ways.
][ >{}
][ >{} Just out of curiosity: is this definitive or are there chances that
][ >{} such "features" may be removed/changed before before Perl6 is actually
][ >{} released in productive form?
][ >
][ >Nothing is definitive, but Larry and Damian seem to be convinced that
][ >the gain of saving 2 characters on an if() are worth sacrificing the
][ >non-significance of whitespace, that I say the chances are small.
][
][ It would be nice if this behaviour could be triggered somehow, say by
][ means of yet another cmd line switch or a pragma...
][
][ But shouldn't Perl6 be the "community rewrite" (IIRC) of Perl? What
][ does the community think here?!?
There are several perl6 mailinglists. Go join them if you want to know.
][ BTW: what would be the best resource for discussing own
][ ideas/questions about feaures of (any future major release of Perl,
][ but then most definitely) Perl6? Please not that I'm talking about
][ (possibly) naive or generic issues, so too technical a
][ forum/board/whatever may not be well suited for them...
Fire up your time machine and go back 3.5 years in time. Submit your RFC.
Or join the mailinglists. (I joined the first perl6 mailinglist the
very first day. I gave up on perl6 the next day).
Abigail
--
perl -weprint\<\<EOT\; -eJust -eanother -ePerl -eHacker -eEOT
Eric J. Roode
Hash: SHA1
Brad Baxter <b...@ginger.libs.uga.edu> wrote in
news:Pine.A41.4.58.03...@ginger.libs.uga.edu:
I think an OO interface is a good idea. If you do that, don't return
the iteration value with the array values. Use a separate method for
that.
Perhaps something like this:
$set = Array::Each->new (@x, @y);
while (my ($x, $y) = $set->each())
{
print "Iteration number ", $set->index(), "\n";
print " x = $x; y = $y\n";
print " last iteration!\n" if $set->exhausted();
}
$set->rewind();
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32) - WinPT 0.5.13
iD8DBQE/19BsY96i4h5M0egRAmQeAKDXldiTn7DoAUwg99VLtKZDdEvfMgCgie64
TKeuP9sACsC0O/+Z2PhhAz8=
=z5kt
-----END PGP SIGNATURE-----
Brad Baxter
> Brad Baxter <b...@ginger.libs.uga.edu> wrote in message news:<Pine.A41.4.58.03...@ginger.libs.uga.edu>...
> > I'm considering making a new module with the tentative name Array::Each.
> >
> > A draft is available here:
> >
> > http://www.vitabrevis.ws/perl/modules/Array/Each.pm
> > http://www.vitabrevis.ws/perl/modules/Array/Each.pod.html
> The code below ............
Hmmm, that's not what it produces for me, but I think I catch your drift.
> I realize that this occurs, because the variable has the same
> reference
> even though it has completely changed. You might want to note
> something
> about breaking out of iteration and how you should call rewind if you
> are
> going to be using the same variable in a loop.
Good point. I think the OO interface would make this moot (meaning that
the scope of the blessed reference should determine the life of the
iterator), but there may be similar situations that the documentation
might make hints about.
> Anyway, I could see how someone might write code that leaves entries
> in your %set variable which are never deleted. This might be a
> problem for a daemon.
Yes. I think the OO interface should take care of this, too.
> Perhaps, some type of syntax as shown below would work.....
> Without keeping a global hash.......
> Of course it would have to be modified to iterate over multiple
> arrays.
>
> (I like your syntax better, I just don't like the way context is
> maintained.
> Although I don't see any better way to do it, while keeping your
> syntax.)
I'm fond of "my syntax" :-), too, but I think OO will win the day.
> I really don't like the idea of the function being named each, but
> that is just my opinion.
Since OO won't export it, I'm still leaning toward 'each'.
Thanks a bunch for the feedback,
Brad
Brad Baxter
> Brad Baxter <b...@ginger.libs.uga.edu> wrote in comp.lang.perl.misc:
> > I'm considering making a new module with the tentative name Array::Each.
> >
> > A draft is available here:
> >
> > http://www.vitabrevis.ws/perl/modules/Array/Each.pm
> > http://www.vitabrevis.ws/perl/modules/Array/Each.pod.html
> By all means, go for an OO approach. This stuff has been shouting
> "object" from the moment we introduced the %i hash with its keys to
> distinguish different iterators.
>
> The user will have to create an iterator object (instead of "spontaneously"
> saying "( $i, $x, $y) = each( @x, @y)"), but it will be much clearer
> what's happening.
I agree.
> > Among other things, this should allow iterating over the same set of
> > arrays using different iterators. Should I bother?
>
> That's one of the advantages of explicit iterators.
>
> > All feedback is appreciated.
>
> Make each() return the index last (after the array elements) instead
> of first. That way the first n values correspond to the n arrays, and
> the index is easy to ignore when it isn't needed.
At first, I didn't like the sound of this, because I had been seeing this
correspondence between array and hash:
my( $index, $value ) = each( @a ) vs. my( $key, $value ) = each( %h )
But then I saw that the more meaningful correspondence might be the case
where someone is deliberately using parallel arrays instead of a hash:
my( $name, $value ) = each( @names, @values )
and may not care about the index. So now I agree with this suggestion.
Thanks!
Brad
Brad Baxter
> anno...@lublin.zrz.tu-berlin.de (Anno Siegel) wrote in message news:<br7051$h2a$1...@mamenchi.zrz.TU-Berlin.DE>...
> > Brad Baxter <b...@ginger.libs.uga.edu> wrote in comp.lang.perl.misc:
> > > I'm considering making a new module with the tentative name Array::Each.
> > >
> > > A draft is available here:
> > >
> > > http://www.vitabrevis.ws/perl/modules/Array/Each.pm
> > > http://www.vitabrevis.ws/perl/modules/Array/Each.pod.html
> > By all means, go for an OO approach. This stuff has been shouting
> > "object" from the moment we introduced the %i hash with its keys to
> > distinguish different iterators.
> Isn't there some type of Iterator package for perl? Why stop at arrays?
> If there would be an OO approach, why not have iterators for many things.
Not that I found. While I agree you can have iterators for many things,
I'm pretty sure this isn't what I personally want to tackle. :-) Your
examples gave me a good idea what you have in mind, but again, I'll plan
for now to stick with the parallel arrays case.
But it does make me wonder if Iterator::Array might be a better name for
the package. However, my own sense is to stay with Array::Each.
Partly this is because a high-level Iterator category makes me think it
ought to supply an abstract framework that would be extended for each kind
of iteration. I don't think this is the usual case for CPAN, it's just
what comes to mind. But that also is not something I would feel
comfortable taking on.
Many thanks,
Brad
Brad Baxter
> Brad Baxter <b...@ginger.libs.uga.edu> wrote in
> news:Pine.A41.4.58.03...@ginger.libs.uga.edu:
> > I'm considering making a new module with the tentative name
> > Array::Each.
> >
> > A draft is available here:
> >
> > http://www.vitabrevis.ws/perl/modules/Array/Each.pm
> > http://www.vitabrevis.ws/perl/modules/Array/Each.pod.html
> I think an OO interface is a good idea. If you do that, don't return
> the iteration value with the array values. Use a separate method for
> that.
>
> Perhaps something like this:
>
> $set = Array::Each->new (@x, @y);
> while (my ($x, $y) = $set->each())
> {
> print "Iteration number ", $set->index(), "\n";
> print " x = $x; y = $y\n";
> print " last iteration!\n" if $set->exhausted();
> }
> $set->rewind();
This sounds good to me, except that I do like Anno's suggestion to return
the iteration value as the last element. Your code above would work the
same--you would just be ignoring that element. I would still have a
method like index(), and I like the addition of exhausted().
Thanks!
Brad
Brad Baxter
> I'm considering making a new module with the tentative name Array::Each.
>
> A draft is available here:
>
> http://www.vitabrevis.ws/perl/modules/Array/Each.pm
> http://www.vitabrevis.ws/perl/modules/Array/Each.pod.html
So far, I've heard from Bryan, Anno, and Eric--many thanks. Not having
heard strong objections to Array::Each, I'm still leaning in that
direction. I'll also recode the module as an OO one, and present the
result for review before uploading to CPAN (assuming it doesn't crash and
burn). I can't say how soon this will be, given the scarcity of tuits
right about now, but I don't expect anyone will necessarily miss it in the
mean time.
Best regards,
Brad
Darren Dunham
> going to be the worst thing that ever happened to Perl.
New Coke?
--
Darren Dunham ddu...@taos.com
Unix System Administrator Taos - The SysAdmin Company
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >