«

Should C<++$_ for -1..1> croak?

Or is it better to leave it as it is?



$ perl -wle'++$_ for 1..1'


$ perl -wle'++$_ for 1'
Modification of a read-only value attempted at -e line 1.


--
Ruud

Dr.Ruud wrote:
> Should C<++$_ for -1..1> croak?
>
> Or is it better to leave it as it is?
>
>
>
> $ perl -wle'++$_ for 1..1'
>
>
> $ perl -wle'++$_ for 1'
> Modification of a read-only value attempted at -e line 1.
>
>

for implicitly aliases $_ to the constant 1, which cannot be incremented.

Steve C wrote:
> Dr.Ruud wrote:
>> Should C<++$_ for -1..1> croak?
>>
>> Or is it better to leave it as it is?
>>
>>
>>
>> $ perl -wle'++$_ for 1..1'
>>
>>
>> $ perl -wle'++$_ for 1'
>> Modification of a read-only value attempted at -e line 1.
>>
>>
>
> for implicitly aliases $_ to the constant 1, which cannot be incremented.

perl -wle 'sub mod{++$_[0]} mod(1)'
Modification of a read-only value attempted at -e line 1.

The for example seems to be consistent behavior, if that's what you're asking.

I guess I would be upset if after calling mod the constant 1 became 2.
That used to happen to me with FORTRAN programs on IBM when I passed a
constant to a sub which modified its parameters.

Steve C <> writes:

> Dr.Ruud wrote:
>> Should C<++$_ for -1..1> croak?
>>
>> Or is it better to leave it as it is?
>>
>>
>>
>> $ perl -wle'++$_ for 1..1'
>>
>>
>> $ perl -wle'++$_ for 1'
>> Modification of a read-only value attempted at -e line 1.
>
> for implicitly aliases $_ to the constant 1, which cannot be
> incremented.

Note that there are two examples and only the last one complains about a
modification of ro value.

--
John Bokma j3b

Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development

On 2010-01-28, Dr.Ruud <rvtol+> wrote:
> Should C<++$_ for -1..1> croak?
> Or is it better to leave it as it is?

Tough call. I reported it many years ago. *Then* it was like this

> perl5.00455 -wle "sub f{ for(1..3) {print $_++ }} f; print q(==); f"
1
2
3
==
2
3
4

This was fixed; nowadays it is "not that bad"...

I know this does not help,
Ilya

On 1/28/2010 7:40 PM, Ilya Zakharevich wrote:
> "sub f{ for(1..3) {print $_++ }} f; print q(==); f"

does your shell do no substitution?

--

"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe"

On 2010-01-29, sreservoir <> wrote:
> On 1/28/2010 7:40 PM, Ilya Zakharevich wrote:
>> "sub f{ for(1..3) {print $_++ }} f; print q(==); f"
>
> does your shell do no substitution?

There is no hope to give command line examples which would work with
all 3 major shell types... This is why I always use q() and qq() in
my posts: one needs to change only two delimiters to suit your shell...

Hope this helps,
Ilya

On 2010-01-29 08:17, Ilya Zakharevich <nospam-> wrote:
> On 2010-01-29, sreservoir <> wrote:
>> On 1/28/2010 7:40 PM, Ilya Zakharevich wrote:
>>> "sub f{ for(1..3) {print $_++ }} f; print q(==); f"
>>
>> does your shell do no substitution?
>
> There is no hope to give command line examples which would work with
> all 3 major shell types...

This is why I avoid posting Perl code in the form
perl -e '...'
It gratuitously involves some shell which may or may not do some
interpolation of its own. The reader must then guess the type of shell
and interpolation (if any) it performs.

If you just post the Perl code:

sub f{ for(1..3) {print $_++ }} f; print q(==); f

it is clear that only the behaviour of perl needs to be considered,
and any shell is irrelevant. To test this, the reader can store it in a
one-line file or use the shell with appropriate quotes.

Besides, if you aren't constrained to one line by the deficiencies of
your shell, you can make the code a bit more readable:

sub f{
for(1..3) {
print $_++
}
}

f;
print q(==);
f

hp

"Peter J. Holzer" <hjp-> wrote:
>On 2010-01-29 08:17, Ilya Zakharevich <nospam-> wrote:
>> On 2010-01-29, sreservoir <> wrote:
>>> On 1/28/2010 7:40 PM, Ilya Zakharevich wrote:
>>>> "sub f{ for(1..3) {print $_++ }} f; print q(==); f"
>>>
>>> does your shell do no substitution?
>>
>> There is no hope to give command line examples which would work with
>> all 3 major shell types...
>
>This is why I avoid posting Perl code in the form
>perl -e '...'
>It gratuitously involves some shell which may or may not do some
>interpolation of its own. The reader must then guess the type of shell
>and interpolation (if any) it performs.

Thank you! Finally someone with some common sense to speak up!

jue

On 2010-01-29, Peter J. Holzer <hjp-> wrote:
>> There is no hope to give command line examples which would work with
>> all 3 major shell types...

> This is why I avoid posting Perl code in the form
> perl -e '...'
> It gratuitously involves some shell which may or may not do some
> interpolation of its own. The reader must then guess the type of shell
> and interpolation (if any) it performs.
>
> If you just post the Perl code:
>
> sub f{ for(1..3) {print $_++ }} f; print q(==); f
>
> it is clear that only the behaviour of perl needs to be considered,
> and any shell is irrelevant.

Having code which may be immediately executed overrides all other
considerations. How would the user KNOW that this is complete
snippet? How would they know the version of Perl it runs under? How
would they know what @ARGV and command-line options are required?

Perl culture is very strongly intertwined with the command-line
culture. If somebody cannot see that ""-delimiters are used, and does
not know about shell quoting semantic variability, I do not care if I
lose this person's attention in the discussion.

> To test this, the reader can store it in a
> one-line file or use the shell with appropriate quotes.

But she, most probably, won't.

> Besides, if you aren't constrained to one line by the deficiencies of
> your shell, you can make the code a bit more readable:
>
> sub f{
> for(1..3) {
> print $_++
> }
> }
>
> f;
> print q(==);
> f

Since I (and many readers) am, this does not matter much, right?

Yours,
Ilya