Ambiguity with lc

Discussion in 'Perl Misc' started by Frank Seitz, Apr 4, 2009.

  1. Frank Seitz

    Frank Seitz Guest

    #!/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
    --
    Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
    Anwendungen für Ihr Internet und Intranet
    Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
    Frank Seitz, Apr 4, 2009
    #1
    1. Advertising

  2. Frank Seitz <> wrote:
    > #!/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
    --
    \ Jens Thoms Toerring ___
    \__________________________ http://toerring.de
    Jens Thoms Toerring, Apr 4, 2009
    #2
    1. Advertising

  3. Frank Seitz

    Frank Seitz Guest

    Jens Thoms Toerring wrote:
    > Frank Seitz <> wrote:
    >> #!/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).


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

    Frank
    --
    Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
    Anwendungen für Ihr Internet und Intranet
    Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
    Frank Seitz, Apr 4, 2009
    #3
  4. On 2009-04-04, Frank Seitz <> wrote:
    > Jens Thoms Toerring wrote:

    *SKIP*
    >> 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).


    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.


    --
    Torvalds' goal for Linux is very simple: World Domination
    Stallman's goal for GNU is even simpler: Freedom
    Eric Pozharski, Apr 4, 2009
    #4
  5. On 2009-04-04, Eric Pozharski <> wrote:
    > On 2009-04-04, Frank Seitz <> wrote:
    >> Jens Thoms Toerring wrote:

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

    >
    > s/would/will/g


    and maybe not.

    *CUT*

    --
    Torvalds' goal for Linux is very simple: World Domination
    Stallman's goal for GNU is even simpler: Freedom
    Eric Pozharski, Apr 5, 2009
    #5
  6. Frank Seitz

    Guest

    On Sat, 04 Apr 2009 13:39:51 +0200, Frank Seitz <> wrote:

    >#!/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
    , Apr 5, 2009
    #6
  7. Frank Seitz

    Guest

    On Sat, 04 Apr 2009 13:39:51 +0200, Frank Seitz <> wrote:

    >#!/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
    , Apr 6, 2009
    #7
  8. Frank Seitz

    Frank Seitz Guest

    Ben Morrow wrote:
    > Quoth 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?

    >
    > 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
    --
    Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
    Anwendungen für Ihr Internet und Intranet
    Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
    Frank Seitz, Apr 6, 2009
    #8
  9. Frank Seitz

    Frank Seitz Guest

    Glenn Jackman wrote:
    > At 2009-04-04 10:17AM, "Frank Seitz" wrote:
    >> I don't believe that anybody means lc($_.'X') when she writes lc.'X'.
    >> I expect lc($_).'X' and nothing else.

    >
    > 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
    --
    Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
    Anwendungen für Ihr Internet und Intranet
    Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
    Frank Seitz, Apr 6, 2009
    #9
  10. Frank Seitz

    Frank Seitz Guest

    wrote:
    >
    > 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
    --
    Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
    Anwendungen für Ihr Internet und Intranet
    Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
    Frank Seitz, Apr 6, 2009
    #10
  11. Frank Seitz

    Frank Seitz Guest

    Ben Morrow wrote:
    > Quoth Frank Seitz <>:
    >>
    >> This is the explanation in perldiag, I know. But I don't understand
    >> what this has to do with my code.

    >
    > 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
    --
    Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
    Anwendungen für Ihr Internet und Intranet
    Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
    Frank Seitz, Apr 6, 2009
    #11
  12. Frank Seitz <> wrote in
    news::

    > Glenn Jackman wrote:
    >> At 2009-04-04 10:17AM, "Frank Seitz" wrote:
    >>> I don't believe that anybody means lc($_.'X') when she writes
    >>> lc.'X'. I expect lc($_).'X' and nothing else.

    >>
    >> 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.


    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 <>
    (remove .invalid and reverse each component for email address)

    comp.lang.perl.misc guidelines on the WWW:
    http://www.rehabitation.com/clpmisc/
    A. Sinan Unur, Apr 6, 2009
    #12
  13. Frank Seitz

    Frank Seitz Guest

    A. Sinan Unur wrote:
    > Frank Seitz <> wrote in
    > news::
    >
    >> Glenn Jackman wrote:
    >>> At 2009-04-04 10:17AM, "Frank Seitz" wrote:
    >>>> I don't believe that anybody means lc($_.'X') when she writes
    >>>> lc.'X'. I expect lc($_).'X' and nothing else.
    >>> 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.

    >
    > 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
    --
    Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
    Anwendungen für Ihr Internet und Intranet
    Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
    Frank Seitz, Apr 6, 2009
    #13
  14. Frank Seitz <> wrote in news:73torqFu2kl7U3
    @mid.individual.net:

    > wrote:

    ....

    >> The compiler gets abmigous if you don't.

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


    Don't worry, no one does ;-)

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

    comp.lang.perl.misc guidelines on the WWW:
    http://www.rehabitation.com/clpmisc/
    A. Sinan Unur, Apr 6, 2009
    #14
  15. On 2009-04-06 13:11, A. Sinan Unur <> wrote:
    > Frank Seitz <> wrote in
    > news::
    >> Glenn Jackman wrote:
    >>> At 2009-04-04 10:17AM, "Frank Seitz" wrote:
    >>>> I don't believe that anybody means lc($_.'X') when she writes
    >>>> lc.'X'. I expect lc($_).'X' and nothing else.
    >>>
    >>> 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.

    >
    > 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
    Peter J. Holzer, Apr 6, 2009
    #15
  16. Frank Seitz

    C.DeRykuks Guest

    On Apr 6, 5:07 am, Frank Seitz <> wrote:
    > Ben Morrow wrote:
    > > Quoth Frank Seitz <>:

    >
    > >> This is the explanation in perldiag, I know. But I don't understand
    > >> what this has to do with my code.

    >
    > > 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.
    >


    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 ...:)

    --
    Charles DeRykus
    C.DeRykuks, Apr 8, 2009
    #16
  17. Frank Seitz

    Frank Seitz Guest

    C.DeRykuks wrote:
    > On Apr 6, 5:07 am, Frank Seitz <> wrote:
    >> Ben Morrow wrote:
    >>> Quoth Frank Seitz <>:
    >>>> This is the explanation in perldiag, I know. But I don't understand
    >>>> what this has to do with my code.
    >>> 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.

    >
    > 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
    --
    Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
    Anwendungen für Ihr Internet und Intranet
    Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
    Frank Seitz, Apr 8, 2009
    #17
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Greg
    Replies:
    0
    Views:
    550
  2. Replies:
    0
    Views:
    558
  3. Stanimir Stamenkov
    Replies:
    1
    Views:
    490
    Stanimir Stamenkov
    Jan 5, 2006
  4. Mark Turney
    Replies:
    11
    Views:
    4,266
    dibeas
    Nov 13, 2006
  5. =?ISO-8859-1?Q?Christian_Engstr=F6m?=

    base/derived ambiguity with gcc, but not with MSVC

    =?ISO-8859-1?Q?Christian_Engstr=F6m?=, Feb 11, 2004, in forum: C++
    Replies:
    2
    Views:
    353
    =?ISO-8859-1?Q?Christian_Engstr=F6m?=
    Feb 12, 2004
Loading...

Share This Page