Ambiguity with lc

F

Frank Seitz

#!/usr/bin/perl

use strict;
use warnings;

my @arr = map {lc.'X'} qw/A B C/;
print "@arr\n";

__END__
Warning: Use of "lc" without parentheses is ambiguous at ./test.pl line 6.
aX bX cX

I don't see the problem. Where is the ambiguity?

Frank
 
J

Jens Thoms Toerring

Frank Seitz said:
#!/usr/bin/perl
use strict;
use warnings;
my @arr = map {lc.'X'} qw/A B C/;
print "@arr\n";
__END__
Warning: Use of "lc" without parentheses is ambiguous at ./test.pl line 6.
aX bX cX
I don't see the problem. Where is the ambiguity?

I guess the question is if you want to lowercase just what's in $_
or the concatenation of $_ with 'X', i.e do you want

lc( $_ ) . 'X' )

or

lc( $_ . 'X' )

The way you've written it it only lc's what's in $_, so you get
"aX bX cX". But if you had writtem

my @arr = map { lc $_ . 'X' } qw/A B C/;

it would output "ax bx cx" (and wouldn't warn).

Regards, Jens
 
F

Frank Seitz

Jens said:
I guess the question is if you want to lowercase just what's in $_
or the concatenation of $_ with 'X', i.e do you want

lc( $_ ) . 'X' )

or

lc( $_ . 'X' )

The way you've written it it only lc's what's in $_, so you get
"aX bX cX". But if you had writtem

my @arr = map { lc $_ . 'X' } qw/A B C/;

it would output "ax bx cx" (and wouldn't warn).

I don't believe that anybody means lc($_.'X') when she writes lc.'X'.
I expect lc($_).'X' and nothing else.

Frank
 
E

Eric Pozharski

Jens Thoms Toerring wrote: *SKIP*
s/would/will/g

I don't believe that anybody means lc($_.'X') when she writes lc.'X'.
I expect lc($_).'X' and nothing else.

There's a kind of idea, that that functions defaulting to I<$_> are
somewhat abused, that such defaulting is for one-liners (programs, but
people). That "idea" isn't that verbose as "use-lexical-filehandles",
but such "idea" exists.
 
S

sln

#!/usr/bin/perl

use strict;
use warnings;

my @arr = map {lc.'X'} qw/A B C/;
print "@arr\n";

__END__
Warning: Use of "lc" without parentheses is ambiguous at ./test.pl line 6.
aX bX cX

I don't see the problem. Where is the ambiguity?

Frank

So have you been invited to rewrite the Perl parser?

No?

What's the big deal? Where is the ambiguity?

Any retard could do it, don't you think?

-sln
 
S

sln

#!/usr/bin/perl

use strict;
use warnings;

my @arr = map {lc.'X'} qw/A B C/;
print "@arr\n";

__END__
Warning: Use of "lc" without parentheses is ambiguous at ./test.pl line 6.
aX bX cX

I don't see the problem. Where is the ambiguity?

Frank

Everybody knows lc.'X' is ambigous. Thats why everybody always uses spaces
that don't turn warnings off. The compiler gets abmigous if you don't.

Perl is so rich.and ambigous. Let this be a lesson to you!

-sln
 
F

Frank Seitz

Ben said:
The sort of thing being warned about is

rand + 5

which means

rand(+5)

rather than

rand() + 5

This is the explanation in perldiag, I know. But I don't understand
what this has to do with my code.
In your case the warning is firing accidentally.

Accidentally? Does this mean it is a bug or deficiency of the Parser?

Frank
 
F

Frank Seitz

Glenn said:
I don't believe anyone trying to write a maintainable program would
write "lc.'x'"

lc lowercases $_ and . concatenates the result with 'X'.
In my opinion this is clean code.

Frank
 
F

Frank Seitz

Everybody knows lc.'X' is ambigous.

I wouldn't have asked if I had known what the problem is.
Thats why everybody always uses spaces
that don't turn warnings off. The compiler gets abmigous if you don't.

I don't know what you want to tell me.

Frank
 
F

Frank Seitz

Ben said:
Neither could I when I wrote that, and I thought the warning was firing
in error. However, it *is* actually ambiguous. Consider

lc.5

This parses as

lc(.5)

rather than

lc() . 5

since the '.' can be interpreted as the start of a number.

Okay, but in my case there is no digit following the dot,
the dot is evidently the binary concatenation operator.

Frank
 
A

A. Sinan Unur

lc lowercases $_ and . concatenates the result with 'X'.
In my opinion this is clean code.

On the other hand, mere mortals may miss the . or may have to check
documentation.

Will $x and $y in the code below contain the same string? I cannot
instaneously answer that question. I have to think about it. That is
what makes this code a maintanence problem:

#!/usr/bin/perl

use strict;
use warnings;

my $v = 'A';

$_ = $v;

my $x = lc . 'X';
my $y = lc $v . 'X';

print "'$_'\n" for $x, $y;

__END__


--
A. Sinan Unur <[email protected]>
(remove .invalid and reverse each component for email address)

comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
 
F

Frank Seitz

A. Sinan Unur said:
On the other hand, mere mortals may miss the . or may have to check
documentation.

Will $x and $y in the code below contain the same string? I cannot
instaneously answer that question. I have to think about it. That is
what makes this code a maintanence problem:

#!/usr/bin/perl

use strict;
use warnings;

my $v = 'A';

$_ = $v;

my $x = lc . 'X';
my $y = lc $v . 'X';

print "'$_'\n" for $x, $y;

For the latter case I agree. In such a case I would always set
parenthesis. The first case is not problematic for me (as Perl adept).

Frank
 
P

Peter J. Holzer

On the other hand, mere mortals may miss the . or may have to check
documentation.

Will $x and $y in the code below contain the same string?
No.

I cannot instaneously answer that question.

Neither can I.
I have to think about it. That is
what makes this code a maintanence problem:

my $v = 'A';

$_ = $v;

my $x = lc . 'X';
my $y = lc $v . 'X';

But it's the latter which is th maintenance problem.
my $x = lc . 'X';

is perfectly clear and unambiguous. But is
my $y = lc $v . 'X';

supposed to mean

my $y = lc($v . 'X');

or

my $y = lc($v) . 'X';

?

Well, I know the answer, but I have to think about it. If I came
across this code I would probably add the parentheses.

So perl warns about the clear and unambiguous code, but not about the
ambiguous code. Somebody got that warning backwards.

hp
 
C

C.DeRykuks

Okay, but in my case there is no digit following the dot,
the dot is evidently the binary concatenation operator.

The Camel, 3rd ed., pg 96-7:

"Another funny thing about named unary operators is
that many of them default to $_ if you don't supply
an argument. However, if you omit the argument but
the token following the named unary operator looks
like it might be the start of an argument,Perl will
get confused because it's expecting a term."

Maybe I'm wrong but I suspect the tokener doesn't look ahead to check
context, ie, that there's no digit. It's confused and figures the next
victim probably will be too ...:)
 
F

Frank Seitz

C.DeRykuks said:
The Camel, 3rd ed., pg 96-7:

"Another funny thing about named unary operators is
that many of them default to $_ if you don't supply
an argument. However, if you omit the argument but
the token following the named unary operator looks
like it might be the start of an argument,Perl will
get confused because it's expecting a term."

Maybe I'm wrong but I suspect the tokener doesn't look ahead to check
context, ie, that there's no digit. It's confused and figures the next
victim probably will be too ...:)

Thank you! I agree. This quotation explains everything!

Frank
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top