Home > Archive > PERL Beginners > October 2006 > Chomping an array
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| Why does:
chomp(reverse(@x);
give an error whereas
@x=reverse(@x);
chomp(@x);
works fine?
Thanks
Anand
| |
| Paul Lalli 2006-10-30, 7:03 pm |
| RCA wrote:
> Why does:
>
> chomp(reverse(@x);
>
> give an error whereas
>
> @x=reverse(@x);
> chomp(@x);
>
> works fine?
Because reverse() returns a list of values that aren't stored anywhere.
chomp() directly modifies its arguments and puts the modified value
back where they were. When you pass just the return value of
reverse(), those values aren't anywhere that can be "put back to".
Paul Lalli
| |
| nobull67@gmail.com 2006-10-30, 7:03 pm |
|
On Oct 24, 4:22 pm, "Paul Lalli" <mri...@gmail.com> wrote:
> RCA wrote:
>
>
>
>
[color=darkred]
> Because reverse() returns a list of values that aren't stored anywhere.
> chomp() directly modifies its arguments and puts the modified value
> back where they were. When you pass just the return value of
> reverse(), those values aren't anywhere that can be "put back to".
Sound like a very good answer.
Pity it's completely wrong! :-)
The real answer is: "Because you can't, so there!"
The only reason you get a "can't modify XXX in YYY" error is because
you do. If you comment out the line of code in the Perl complier that
generates this error then (AFAIK) nothing will break but now you _will_
be able to modify reverse() in chomp() and so on.
Even without hacking the Perl compiler you can side-step the compiler
error with an identity function:
# An identity function - just returns its argument list
sub can_modify:lvalue { @_[ 0 .. $#_ ] }
chomp(can_modify(reverse(@x)));
Of course in this particular case there's no point as the next effect
of processing the elements of @x in reverse order is exactly the same
as:
chomp(@x);
IMNSO the "can't modify XXX in YYY" is a waste of time. It prevents you
_deliberately_ writing code that is _obviously_ trying to modify the
return value of a function whilst it doesn't in any way prevent you
_accidently_ writing code that is _unobviously_ doing so.
By doing so it serves only to give a false sense of security by making
you believe what Paul said. Consider...
# What can go wrong if you believe what Paul said
for my $e (reverse @x ) {
print "$e\n";
# I don't worry that this will corrupt @x because I believe the
# return value of reverse() is something completely separate
# from @x
$e++;
print "$e\n";
}
| |
| Paul Lalli 2006-10-30, 7:03 pm |
| nobull67@gmail.com wrote:
> On Oct 24, 4:22 pm, "Paul Lalli" <mri...@gmail.com> wrote:
>
> Sound like a very good answer.
>
> Pity it's completely wrong! :-)
>
> The real answer is: "Because you can't, so there!"
>
> The only reason you get a "can't modify XXX in YYY" error is because
> you do. If you comment out the line of code in the Perl complier that
> generates this error then (AFAIK) nothing will break but now you _will_
> be able to modify reverse() in chomp() and so on.
>
> Even without hacking the Perl compiler you can side-step the compiler
> error with an identity function:
>
> # An identity function - just returns its argument list
> sub can_modify:lvalue { @_[ 0 .. $#_ ] }
>
> chomp(can_modify(reverse(@x)));
>
> Of course in this particular case there's no point as the next effect
> of processing the elements of @x in reverse order is exactly the same
> as:
>
> chomp(@x);
>
> IMNSO the "can't modify XXX in YYY" is a waste of time. It prevents you
> _deliberately_ writing code that is _obviously_ trying to modify the
> return value of a function whilst it doesn't in any way prevent you
> _accidently_ writing code that is _unobviously_ doing so.
>
> By doing so it serves only to give a false sense of security by making
> you believe what Paul said. Consider...
>
> # What can go wrong if you believe what Paul said
>
> for my $e (reverse @x ) {
> print "$e\n";
> # I don't worry that this will corrupt @x because I believe the
> # return value of reverse() is something completely separate
> # from @x
> $e++;
> print "$e\n";
> }
I'm not entirely sure why you felt the need to be insulting. If I'm
wrong, and I clearly am in this case, so be it. If you're bitter
towards the makers of Perl for inserting this restriction, be bitter
towards them.
Regardless, I thank you for the correction and the information.
Paul Lalli
| |
| nobull67@gmail.com 2006-10-30, 7:03 pm |
|
On Oct 24, 6:16 pm, "Paul Lalli" <mri...@gmail.com> wrote:
> nobul...@gmail.com wrote:
>
>
[color=darkred]
> I'm not entirely sure why you felt the need to be insulting.
I'm not entirely sure why you felt the need to feel insulted.
> If you're bitter
> towards the makers of Perl for inserting this restriction, be bitter
> towards them.
Please go back and re-read what I said without any preconception that
it is an insult aimed at you.
I don't attack you, I attack the error message because it causes
intelegent people (either conciously or unconciously) to arrive at the
misconception that you voiced.
This misconception in turn leads to mistakes. I know this from
first-hand experience. (That is to say, I laboured under this same
misconception for a while).
| |
|
| Thanks for the response.
Is this kind of restriction unique to chomp? Or is it applicable to all
functions? For example, print(reverse(@x)) works just fine. If this is
unique to chomp, does it qualify for a bug in Perl?
Thanks
nobull67@gmail.com wrote:
> On Oct 24, 6:16 pm, "Paul Lalli" <mri...@gmail.com> wrote:
>
>
> I'm not entirely sure why you felt the need to feel insulted.
>
>
> Please go back and re-read what I said without any preconception that
> it is an insult aimed at you.
>
> I don't attack you, I attack the error message because it causes
> intelegent people (either conciously or unconciously) to arrive at the
> misconception that you voiced.
>
> This misconception in turn leads to mistakes. I know this from
> first-hand experience. (That is to say, I laboured under this same
> misconception for a while).
| |
| Paul Lalli 2006-10-30, 7:03 pm |
| RCA wrote:
> Is this kind of restriction unique to chomp? Or is it applicable to all
> functions? For example, print(reverse(@x)) works just fine. If this is
> unique to chomp, does it qualify for a bug in Perl?
No, it's any function that directly modifies its arguments, such as
push and pop.
Whether it's a bug or not... I dunno. The docs don't specifically say
what it "should" do either way. I would call it a feature request at
best.
Paul Lalli
| |
| nobull67@gmail.com 2006-10-30, 7:03 pm |
| On Oct 24, 8:15 pm, "Paul Lalli" <mri...@gmail.com> wrote:
> RCA wrote:
[color=darkred]
> No, it's any function that directly modifies its arguments, such as
> push and pop.
I hate to correct you again but the error you get from pop(reverse(@x))
is "Type of arg 1 to pop must be array (not reverse)" which is a
completely different error. It is a function prototype error.
There are not that many builtin functions that take a list or scalar
and modify it.
Off the top of my head I can only think of chop() and chomp().
| |
| Paul Lalli 2006-10-30, 7:03 pm |
| nobull67@gmail.com wrote:
> On Oct 24, 8:15 pm, "Paul Lalli" <mri...@gmail.com> wrote:
>
>
> I hate to correct you again but the error you get from pop(reverse(@x))
> is "Type of arg 1 to pop must be array (not reverse)" which is a
> completely different error. It is a function prototype error.
The encompassing *issue* is the same. Modifying a value based on some
transformation of that value. Whether its implemented in the backend
code differently or not is besides the point. It's clearly a
philosophical restriction that Perl has decided to make.
IMO, anyway.
In any case, I'm done with this thread. Thank you, again, nobull, for
the corrections and information.
Paul Lalli
|
|
|
|
|