[23575] in Perl-Users-Digest
Perl-Users Digest, Issue: 5782 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Nov 11 14:10:45 2003
Date: Tue, 11 Nov 2003 11:10:17 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 11 Nov 2003 Volume: 10 Number: 5782
Today's topics:
Re: Sort array of objects using a method (Anno Siegel)
Re: Sort array of objects using a method <uri@stemsystems.com>
Re: Sort array of objects using a method <uri@stemsystems.com>
Re: Sort array of objects using a method <uri@stemsystems.com>
Re: Sort array of objects using a method (Anno Siegel)
Re: Style question: map versus foreach <dmcbride@naboo.to.org.no.spam.for.me>
Re: Style question: map versus foreach <dmcbride@naboo.to.org.no.spam.for.me>
Re: Style question: map versus foreach <usenet@morrow.me.uk>
Re: Style question: map versus foreach <abigail@abigail.nl>
Re: Style question: map versus foreach <grazz@pobox.com>
Re: Style question: map versus foreach (Roy Johnson)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 11 Nov 2003 14:52:11 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Sort array of objects using a method
Message-Id: <boqt2r$h66$3@mamenchi.zrz.TU-Berlin.DE>
Tassilo v. Parseval <tassilo.parseval@post.rwth-aachen.de> wrote in comp.lang.perl.misc:
[sorting, the Schwartzian transform]
> (hmmh, Guttman-Rosler can't be used on objects, can it?):
No, not directly. It relies on the ability to retrieve the original
element through a substr() operation. To do that with references would
require extra means, like accessing an auxiliary array or hash.
Let's see:
w = \ qw( 4 2 7 5 9 12 6); # raw is a list of scalar refs
my $size = 16;
my @sorted = map $raw[ substr( $_, $size)], # retrieve originals
sort # default string sort
map sprintf( "%${size}s%d", ${ $raw[ $_]}, $_),# build sortable strings
0 .. $#raw;
print "$$_\n" for @sorted;
Ah, that doesn't look half bad. It preserves the essential of the GRT,
default sorting, and the only extra cost is another access to the
original array (okay, and indexed access when the strings are built).
Is that still GRT? Uri?
Anno
------------------------------
Date: Tue, 11 Nov 2003 16:15:40 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Sort array of objects using a method
Message-Id: <x7u15ayj83.fsf@mail.sysarch.com>
>>>>> "TvP" == Tassilo v Parseval <tassilo.parseval@rwth-aachen.de> writes:
TvP> A good moment to also mention one of the transforms as I wouldn't want
TvP> to call two methods n*log(n) times. Schwartzian transform comes to mind
TvP> (hmmh, Guttman-Rosler can't be used on objects, can it?):
the GRT can be used on a list of objects or refs. you preprocess the
list to make the key strings and then append a sequence number. you sort
that and extract the sequence number and index with that back into the
original list. this is covered in the sort paper.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Tue, 11 Nov 2003 16:20:16 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Sort array of objects using a method
Message-Id: <x7r80eyj0g.fsf@mail.sysarch.com>
>>>>> "AS" == Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> writes:
AS> No, not directly. It relies on the ability to retrieve the original
AS> element through a substr() operation. To do that with references would
AS> require extra means, like accessing an auxiliary array or hash.
AS> Let's see:
AS> w = \ qw( 4 2 7 5 9 12 6); # raw is a list of scalar refs
AS> my $size = 16;
AS> my @sorted = map $raw[ substr( $_, $size)],a # retrieve originals
AS> sort # default string sort
AS> map sprintf( "%${size}s%d", ${ $raw[ $_]}, $_),# build sortable strings
AS> 0 .. $#raw;
AS> print "$$_\n" for @sorted;
AS> Ah, hat doesn't look half bad. It preserves the essential of the GRT,
AS> default sorting, and the only extra cost is another access to the
AS> original array (okay, and indexed access when the strings are built).
AS> Is that still GRT? Uri?
i would say it is. the main point of the GRT is to call sort with no
comparison block. all the various techniques used to make that happen
all fall under the same GRT umbrella IMNSHO. :)
my coauthor (larry rosler) would prefer to use pack instead of sprintf
and use a binary 4 byte sequence field and also binary formats for the
real keys. it makes for a shorter key which makes for a faster
comparison. i don't think i ever benchmarked pack vs sprintf in the GRT.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Tue, 11 Nov 2003 16:21:12 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Sort array of objects using a method
Message-Id: <x7oeviyiyv.fsf@mail.sysarch.com>
>>>>> "M" == Marcus <bayrazone@web.de> writes:
M> Hey, it works.
M> The hint with the special variable was the key.
it wasn't a hint, it was a full answer. now please rtfm on sort and
learn about $a and $b.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: 11 Nov 2003 17:13:44 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Sort array of objects using a method
Message-Id: <bor5c8$nf2$1@mamenchi.zrz.TU-Berlin.DE>
Uri Guttman <uri@stemsystems.com> wrote in comp.lang.perl.misc:
> >>>>> "AS" == Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> writes:
>
> AS> No, not directly. It relies on the ability to retrieve the original
> AS> element through a substr() operation. To do that with references would
> AS> require extra means, like accessing an auxiliary array or hash.
>
> AS> Let's see:
>
> AS> w = \ qw( 4 2 7 5 9 12 6); # raw is a list of scalar refs
>
> AS> my $size = 16;
> AS> my @sorted = map $raw[ substr( $_, $size)],a # retrieve
> originals
> AS> sort # default
> string sort
> AS> map sprintf( "%${size}s%d", ${ $raw[ $_]}, $_),# build
> sortable strings
> AS> 0 .. $#raw;
>
> AS> print "$$_\n" for @sorted;
>
> AS> Ah, hat doesn't look half bad. It preserves the essential of the GRT,
> AS> default sorting, and the only extra cost is another access to the
> AS> original array (okay, and indexed access when the strings are built).
> AS> Is that still GRT? Uri?
>
> i would say it is. the main point of the GRT is to call sort with no
> comparison block. all the various techniques used to make that happen
> all fall under the same GRT umbrella IMNSHO. :)
Well, that's how it works, isn't it? :)
> my coauthor (larry rosler) would prefer to use pack instead of sprintf
> and use a binary 4 byte sequence field and also binary formats for the
> real keys. it makes for a shorter key which makes for a faster
> comparison. i don't think i ever benchmarked pack vs sprintf in the GRT.
"Sprintf" and "pack/unpack" are comparatively slow functions, for similar
reasons: the do a run-time interpretation of a format string. One would
probably want to factor them out to see the influence of key length on
sorting efficiency.
Another variant is to use an array slice to put the final sorted list
together: "@raw[ map substr( $_, ...), sort ... ]". It's less readable,
imo, so to be acceptable it would have to be faster, which I doubt.
Anno
------------------------------
Date: Tue, 11 Nov 2003 16:03:28 GMT
From: Darin McBride <dmcbride@naboo.to.org.no.spam.for.me>
Subject: Re: Style question: map versus foreach
Message-Id: <kL7sb.370510$9l5.366840@pd7tw2no>
Abigail wrote:
> Darin McBride (dmcbride@naboo.to.org.no.spam.for.me) wrote on MMMDCCXXIV
> September MCMXCIII in <URL:news:grWrb.362981$pl3.319787@pd7tw3no>:
> @@ Abigail wrote:
> @@
> @@ > But could you give an objective reason why foreach is "clearer" than
> @@ > map (after defining what "clearer" is)? Or is it your own preference?
> @@
> @@ <sigh> I thought I had. Let me try again:
> @@
> @@ The only real difference between map and foreach is that map returns a
> @@ value, while foreach doesn't [1]. Thus, if you intend on ignoring the
> @@ return, don't create it in the first place and just use foreach.
>
> map in void context has never returned anything. No function in void
> context has ever returned anything. How could it - if it returned
> something, it couldn't have been in void context. Now, up to 2 versions
> ago, map created a temporary list, even if it didn't need it. That has
> now been fixed.
sub foo()
{
return qw(this is a small array);
}
foo();
And you're saying something in void context doesn't return anything?
No, I think perlstyle is right - map returns something (or at least it
did). The VM cleans it up by deallocating it immediately (or at the
end of the calling block, I'm not exactly sure when). But it is
returned.
Now with the map "fix", it won't create the array. And thus it won't
return anything. However, given that the difference between map and
foreach was solely that return difference, I don't see a point behind
the patch.
> @@ > What makes foreach cleaner than while? Or is while cleaner than
> @@ > foreach? Which one ought to go? Or can we have foreach, for, while,
> @@ > until, goto, and bare blocks, but not map in void context?
> @@
> @@ While vs foreach is another discussion (I wish we'd stick to a single
> @@ topic, but that's not generally possible on usenet, I suspect). If
> the
> @@ only data I have to work with is whether we're in void context or not,
> @@ then neither while nor foreach are different. However, they have
> other
> @@ strengths which would come up should we actually debate those. Again,
> @@ use whichever one makes the most readable sense.
>
> The latter is a good remark. That's why I sometimes use while, sometimes
> for/foreach, and sometimes map in void context. See, there is a difference
> how you read them:
>
> map ACTION DATA;
> for DATA ACTION;
>
> If I want to have the focus on the action, I prefer map. If I want to
> focus on the action, I prefer for. But focus isn't the only thing that's
> important for readability. I prefer shorter things before larger things.
> So, if my block is large, I'll prefer to use for. But if the data is
> coming from a long and complex expression, I'll favour map.
I see what you're saying - unfortunately, to me the simple perldoc on
map makes the void context of map counterintuitive: "... and returns
the list value composed of ..." And thus, those of us who do not have
any LISP background, have a certain expectation that you're using the
function according to the docs...
> @@ Until vs while is easy - again, the most readable one wins. If your
> @@ assertion is positive, use while, if it is negative, use until.
>
> So, you decide on for vs while and while vs until on a case by case
> basis. That's good. However, you dismiss map right away.
No - I use map more than I use for or foreach. But that's primarily
because I am mapping problem spaces from one space to another more than
I am simply looping through constructs.
> @@ > :: o Avoid using grep() (or map()) or `backticks` in a void
> @@ > :: context, that is, when you just throw away their
> @@ > :: return values. Those functions all have return val-
> @@ > :: ues, so use them. Otherwise use a foreach() loop or
> @@ > :: the system() function instead.
> @@ > ::
> @@ > :: I think this is the whole debate. Unfortunately, there's no real
> @@ > :: explicit justification here.
> @@ >
> @@ > Which makes it just the personal preference of one man, doesn't it?
> @@
> @@ No - it means that the perlstyle authors (who are probably more
> @@ proficient in perl than the both of us put together) thought this
> would
> @@ be obvious and unneeding of justification.
>
> Well, apparently it isn't obvious, and in dire need of a justification.
> But I don't think Larry is going to do that. Some fragments of perlstyle:
>
> Larry has his reasons for each of these things, but he
> doesn't claim that everyone else's mind works the same as
> his does.
And Larry probably has better knowledge of perl than the rest of us.
Being a linguist rather than a purist, he doesn't force us to do things
his way, but that doesn't mean his thoughts aren't likely to be better.
[ first element from perlstyle under the above quote deleted for space
reasons... this is getting too damned long already ;-> ]
> See? Larry thinks that it's important that you mention the main point
> first. So, if the main point is the action, not the data it acts upon,
> you would write:
>
> map ACTION DATA;
>
> and not
>
> for DATA ACTION;
None of the examples are ignoring return codes, which is also mentioned
explicitly later on in the perlstyle document (as I quoted earlier).
> @@ > Ah, yes. Logical. There are thousands and thousands of user defined
> @@ > functions whose return value isn't collected. There are many Perl
> @@ > defined functions and operators whose return value isn't collected.
> @@ >
> @@ > Noone ever makes a fuss. But if the function of which the return
> @@
> @@ I do. If there are two user defined functions that do exactly the
> same
> @@ thing, but one allocates and returns an array, and the other does not
> @@ but has the same desired side effects, I would expect people to use
> the
> @@ appropriate one depending on whether they want the array returned or
> @@ not. I don't see any difference.
>
> There are two points against that:
>
> 1) map in void context *doesn't* allocated an array whose
> values remained unused.
Perhaps if you work exclusively with perl 5.8+, that might be true.
However, this doesn't work for two points:
1a) Some of us still work in shops that haven't upgraded from 5.6 yet
(no matter how hard I've pushed)
1b) map still allocates that array *conceptually* in the reader's
mind, even if no allocation actually takes place on the physical
machine.
> 2) it goes against all ideas of encapsulation. If in order
> to use a module, I would first have to study the implementation
> of its functions, why bother? I could write my own. But you
> go further, you require people to first have studied the
> implementation of perl before they can pick the "right way".
> I presume you have carefully studied all the libraries Perl
> links in as well?
Who said anything about studying the implementation? I haven't studied
the implementation of map or for either - only their docs. I *would*
expect that you would first study the perldoc on the module before
trying to use it... and if it documented two functions doing the same
thing, one that allocated and returned another object (whether ARRAY,
HASH or real object), and another that did exactly the same thing
without that allocation and return, then the point still stands.
> @@ > I really don't get it. map in void context isn't doing anything else
> @@ > than the countless of other functions in void context that are called
> @@ > because of their side effects. Yet it sparks gigabytes of
> discussions. @@
> @@ Only because there is an exact duplicate of map functionally that is
> @@ there for void context.
>
> There is also an exact duplicate of 'unless' (which even takes less
> characters to type). Should 'unless' be avoided as well? The functionality
Um, where did I say that? Are you fond of putting words in my mouth?
This is the same as the while/until comparison above: use if for
positive assertions, unless for negative assertions. "unless ($foo) {}"
is way more readable than "if (not $foo) {}". Use the right tool for
the job.
> of while() can also exactly be duplicated with bare blocks. Should
> while() be avoided? If the answers are 'no', then why is it so bad
> there's another way of doing a map in void context?
Who said it was bad? I said it was goodness - so use the right tool
for the job!
> @@ > Then you shouldn't be programming in Perl. Because in Perl, you can't
> @@ > do much useful without side effects.
> @@
> @@ Hmmm... I dunno - I've managed to do a lot of useful stuff without
> side
> @@ effects in perl.
>
> Really? Could you show some code? Remember, assignment and print are
> only useful because of their side effects.
I respectfully must disagree with your definition of "side effects".
------------------------------
Date: Tue, 11 Nov 2003 16:05:47 GMT
From: Darin McBride <dmcbride@naboo.to.org.no.spam.for.me>
Subject: Re: Style question: map versus foreach
Message-Id: <vN7sb.370513$9l5.268890@pd7tw2no>
Calle Dybedahl wrote:
>>>>>> "Darin" == Darin McBride <dmcbride@naboo.to.org.no.spam.for.me>
>>>>>> writes:
>
>> The only real difference between map and foreach is that map returns a
>> value, while foreach doesn't [1]. Thus, if you intend on ignoring the
>> return, don't create it in the first place and just use foreach.
>
> But map *doesn't* create a list to return when you use it in a void
> context. So the choice between map or foreach does become one of
> simple personal preference.
Which version of perl are you using? I'm still stuck on 5.6.0 and
5.6.1 at work.
>> No - it means that the perlstyle authors (who are probably more
>> proficient in perl than the both of us put together) thought this
>> would be obvious and unneeding of justification.
>
> Argumentation by appeal to authority is pretty weak. That you're also
> wrong only makes it worse, Abigail knows at least as much about Perl
> as whoever wrote perlstyle (TomC probably, since it doesn't have any
> author information in it).
Knowing perl and knowing perl style is not necessarily the same thing.
I'm not debating Abigail's knowledge of perl (as I believe mine to be
relatively extensive as well). But we still disagree on calling
functions that document array returns in void context when an
equivalent function exists that documents that there is no return (or
fails to document a return).
------------------------------
Date: Tue, 11 Nov 2003 17:00:12 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Style question: map versus foreach
Message-Id: <bor4is$jqr$1@wisteria.csv.warwick.ac.uk>
Darin McBride <dmcbride@naboo.to.org.no.spam.for.me> wrote:
> Abigail wrote:
> > map in void context has never returned anything. No function in void
> > context has ever returned anything. How could it - if it returned
> > something, it couldn't have been in void context. Now, up to 2 versions
> > ago, map created a temporary list, even if it didn't need it. That has
> > now been fixed.
>
> sub foo()
> {
> return qw(this is a small array);
> }
>
> foo();
>
> And you're saying something in void context doesn't return anything?
my $x = foo();
And you're saying that this returns a list?
> However, given that the difference between map and
> foreach was solely that return difference, I don't see a point behind
> the patch.
I don't think that is 'given', at least not by Abigail. Hence the
argument...
> > There are two points against that:
> >
> > 1) map in void context *doesn't* allocated an array whose
> > values remained unused.
>
> Perhaps if you work exclusively with perl 5.8+, that might be true.
> However, this doesn't work for two points:
> 1a) Some of us still work in shops that haven't upgraded from 5.6 yet
> (no matter how hard I've pushed)
> 1b) map still allocates that array *conceptually* in the reader's
> mind, even if no allocation actually takes place on the physical
> machine.
Err, no... at least, not in my mind; any more than
my $x = 5;
conceptually allocates a scalar return value. As pointed out above, a
function called in void context *never* conceptually allocates a
return value. The fact that map in fact did so was a bug.
> > Really? Could you show some code? Remember, assignment and print are
> > only useful because of their side effects.
>
> I respectfully must disagree with your definition of "side effects".
About the only objective definition of 'side-effect' is 'any effect a
function has other than its return value'. Yes, this is Lisp-ish. No,
that does not make it wrong.
Ben
--
. | .
\ / The clueometer is reading zero.
. .
__ <-----@ __ ben@morrow.me.uk
------------------------------
Date: 11 Nov 2003 17:01:35 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: Style question: map versus foreach
Message-Id: <slrnbr25fe.gi2.abigail@alexandra.abigail.nl>
Darin McBride (dmcbride@naboo.to.org.no.spam.for.me) wrote on MMMDCCXXIV
September MCMXCIII in <URL:news:kL7sb.370510$9l5.366840@pd7tw2no>:
//
// I see what you're saying - unfortunately, to me the simple perldoc on
// map makes the void context of map counterintuitive: "... and returns
// the list value composed of ..." And thus, those of us who do not have
// any LISP background, have a certain expectation that you're using the
// function according to the docs...
But even without a LISP background, you must know it's good to read
past the first sentence. The first two sentences are (and this is from
the 5.6.0 doc):
Evaluates the BLOCK or EXPR for each element of
LIST (locally setting `$_' to each element) and
returns the list value composed of the results of
each such evaluation. In scalar context, returns
the total number of elements so generated.
Considering that void context is a special version of scalar context,
the notion that map in void context would return a list *cannot* be
based on the documentation. At best, you would be discarding a *single*
value - just like do you when using print in void context.
// > @@ Until vs while is easy - again, the most readable one wins. If your
// > @@ assertion is positive, use while, if it is negative, use until.
// >
// > So, you decide on for vs while and while vs until on a case by case
// > basis. That's good. However, you dismiss map right away.
//
// No - I use map more than I use for or foreach. But that's primarily
// because I am mapping problem spaces from one space to another more than
// I am simply looping through constructs.
Well, we were discussing loops where we aren't interested in return values.
That is, where you could use map in void context.
// > @@ > :: o Avoid using grep() (or map()) or `backticks` in a void
// > @@ > :: context, that is, when you just throw away their
// > @@ > :: return values. Those functions all have return val-
// > @@ > :: ues, so use them. Otherwise use a foreach() loop or
// > @@ > :: the system() function instead.
// > @@ > ::
// > @@ > :: I think this is the whole debate. Unfortunately, there's no real
// > @@ > :: explicit justification here.
// > @@ >
// > @@ > Which makes it just the personal preference of one man, doesn't it?
// > @@
// > @@ No - it means that the perlstyle authors (who are probably more
// > @@ proficient in perl than the both of us put together) thought this
// > would
// > @@ be obvious and unneeding of justification.
// >
// > Well, apparently it isn't obvious, and in dire need of a justification.
// > But I don't think Larry is going to do that. Some fragments of perlstyle:
// >
// > Larry has his reasons for each of these things, but he
// > doesn't claim that everyone else's mind works the same as
// > his does.
//
// And Larry probably has better knowledge of perl than the rest of us.
// Being a linguist rather than a purist, he doesn't force us to do things
// his way, but that doesn't mean his thoughts aren't likely to be better.
I've heard Larry saying he seldomly uses 'strict' (and he had the code to
prove it). Damian, another rather well known Perl programmer hardly uses
'strict' either. Does that knowledge now make you stop using 'strict'? Or
do you form your own opinion on that? I use map in void context because
*I* think it's ok, I'm not going to hide myself behind someone who might
be a better programmer.
// Who said anything about studying the implementation? I haven't studied
// the implementation of map or for either - only their docs. I *would*
// expect that you would first study the perldoc on the module before
// trying to use it... and if it documented two functions doing the same
// thing, one that allocated and returned another object (whether ARRAY,
// HASH or real object), and another that did exactly the same thing
// without that allocation and return, then the point still stands.
Here's the 5.6.0 (because you still use that) doc about map. Could you
point out where in the doc it says it's allocating an array when map is
used in void context?
map EXPR,LIST
Evaluates the BLOCK or EXPR for each element of
LIST (locally setting `$_' to each element) and
returns the list value composed of the results of
each such evaluation. In scalar context, returns
the total number of elements so generated. Evalu-
ates BLOCK or EXPR in list context, so each ele-
ment of LIST may produce zero, one, or more ele-
ments in the returned value.
@chars = map(chr, @nums);
translates a list of numbers to the corresponding
characters. And
%hash = map { getkey($_) => $_ } @array;
is just a funny way to write
%hash = ();
foreach $_ (@array) {
$hash{getkey($_)} = $_;
}
Note that, because `$_' is a reference into the
list value, it can be used to modify the elements
of the array. While this is useful and supported,
it can cause bizarre results if the LIST is not a
named array. Using a regular `foreach' loop for
this purpose would be clearer in most cases. See
also the grep entry elsewhere in this document for
an array composed of those items of the original
list for which the BLOCK or EXPR evaluates to
true.
// > @@ > Then you shouldn't be programming in Perl. Because in Perl, you can't
// > @@ > do much useful without side effects.
// > @@
// > @@ Hmmm... I dunno - I've managed to do a lot of useful stuff without
// > side
// > @@ effects in perl.
// >
// > Really? Could you show some code? Remember, assignment and print are
// > only useful because of their side effects.
//
// I respectfully must disagree with your definition of "side effects".
A language construct that modifies the state of the system. The most
common side-effects are assignment, input and output. A language without
side-effects is purely-functional - execution consists of the evaluation
of an expression and all subexpressions are referentially transparent.
http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=side+effect&action=Search
Now, you can make up your own definitions, but that's leading nowhere.
Abigail
--
perl -le 's[$,][join$,,(split$,,($!=85))[(q[0006143730380126152532042307].
q[41342211132019313505])=~m[..]g]]e and y[yIbp][HJkP] and print'
------------------------------
Date: Tue, 11 Nov 2003 18:24:48 GMT
From: Steve Grazzini <grazz@pobox.com>
Subject: Re: Style question: map versus foreach
Message-Id: <QP9sb.22730$y95.7349@nwrdny01.gnilink.net>
Ben Morrow <usenet@morrow.me.uk> wrote:
> Darin McBride <dmcbride@naboo.to.org.no.spam.for.me> wrote:
>> Abigail wrote:
>> > map in void context has never returned anything. No function in void
>> > context has ever returned anything.
>>
>> sub foo()
>> {
>> return qw(this is a small array);
>> }
>>
>> foo();
>>
>> And you're saying something in void context doesn't return anything?
>
> my $x = foo();
>
> And you're saying that this returns a list?
I can't answer for Darin, but I think it does return a list.
% perl -Dts -le 'sub f { "one", "two", "three" } f()'
EXECUTING...
=>
(-e:0) enter
=>
(-e:0) nextstate
=>
(-e:1) pushmark
=> *
(-e:1) gv(main::f)
=> * GV()
(-e:1) entersub
=>
(-e:1) nextstate
=>
(-e:1) pushmark
=> *
(-e:1) const(PV("one"\0))
=> * PV("one"\0)
(-e:1) const(PV("two"\0))
=> * PV("one"\0) PV("two"\0)
(-e:1) const(PV("three"\0))
=> * PV("one"\0) PV("two"\0) PV("three"\0)
(-e:1) list
=> PV("three"\0)
(-e:1) leavesub
=> PV("three"\0)
(-e:1) leave
This is void context, of course, and commas instead of qw(), but it
works just like your example. The subroutine returns a list and a
list in void or scalar context evaluates [pp.c: pp_list] to its last
element.
I suppose it would also be possible to say that the subroutine returns
the *result* of evaluating a list in void context. And likewise, that
this one returns the result of evaluating an array in scalar context:
% perl -Ds -le 'sub f { @INC } scalar f()'
But I'd rather say that this returns an array.
The more common explanation -- that the comma operator in scalar
context works "like it does in C", i.e. evaluating and discarding its
LHS and returning its RHS -- also fits the result, but it's not quite
as accurate.
--
Steve
------------------------------
Date: 11 Nov 2003 10:37:23 -0800
From: rjohnson@shell.com (Roy Johnson)
Subject: Re: Style question: map versus foreach
Message-Id: <3ee08638.0311111037.25e6afc@posting.google.com>
Ben Morrow <usenet@morrow.me.uk> wrote in message news:<bonpl5$4cm$1@wisteria.csv.warwick.ac.uk>...
> It also gives a specific use for map in void context: to call a
> function in list context but discard the result.
Which is another thing that smacks of bad practice.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 5782
***************************************
