Professional Web Applications Themes

Oddity with the x and . operators - PERL Miscellaneous

I've run into something that has me totally puzzled. If I do this: print "foo".("." x 5); as expected, I get: foo..... However, if I do: print ("." x 5)."foo"; I get only: ..... Why does the "foo" get discarded? I can get around this by changing the code to: print scalar("." x 5)."foo" But, according to perlop, I wouldn't think this should be necessary: "In scalar context or if the left operand is not enclosed in parentheses, it returns a string consisting of the left operand repeated the number of times specified by the right operand." Shouldn't the use ...

  1. #1

    Default Oddity with the x and . operators

    I've run into something that has me totally puzzled. If I do this:

    print "foo".("." x 5);

    as expected, I get:

    foo.....

    However, if I do:

    print ("." x 5)."foo";

    I get only:

    .....

    Why does the "foo" get discarded?

    I can get around this by changing the code to:

    print scalar("." x 5)."foo"

    But, according to perlop, I wouldn't think this should be necessary:

    "In scalar context or if the left operand is not enclosed in
    parentheses, it returns a string consisting of the left operand repeated
    the number of times specified by the right operand."

    Shouldn't the use of the '.' operator outside be sufficient to cause the
    parenthetical part to be considered a scalar? Even if it's not, and the
    bit inside the parens evaluates to a single-element list, I would still
    expect to see:

    1foo

    --
    Dan Wilga edu
    ** Remove the -MUNGE in my address to reply **
    Dan Guest

  2. #2

    Default Re: Oddity with the x and . operators

    In article <mtholyoke.edu>, Dan Wilga wrote:
    [cut] 

    The argument to print is '"." x 5'. The return value from print
    is concatenated with the string "foo" and the result is then
    thrown away.

    --
    Andreas Kähäri
    Andreas Guest

  3. #3

    Default Re: Oddity with the x and . operators

    Dan Wilga <edu> wrote in news:dwilga-MUNGE-
    mtholyoke.edu:
     

    print (("." x 5)."foo");


    --
    A. Sinan Unur
    edu
    Remove dashes for address
    Spam bait: mailto:gov
    A. Guest

  4. #4

    Default Re: Oddity with the x and . operators

    Dan Wilga wrote: 
     
     
     

    print +("." x 5)."foo";

    hth, tina
    --
    http://www.tinita.de/ \ enter__| |__the___ _ _ ___
    http://Movies.tinita.de/ \ / _` / _ \/ _ \ '_(_-< of
    http://www.perlquotes.de/ \ \ _,_\ __/\ __/_| /__/ perception
    -my address is currently unreachable due to the Swen.A virus-
    Tina Guest

  5. #5

    Default Re: Oddity with the x and . operators

    Dan Wilga <edu> wrote: 

    The left paranthesis is being consumed by the print operator, and the
    concatenation operator has lower precedence. The perlop man page says:
    If any list operator (print(), etc.) or any unary operator
    (chdir(), etc.) is followed by a left parenthesis as the
    next token, the operator and arguments within parentheses
    are taken to be of highest precedence, just like a normal
    function call.

    See what perl tells you:
    $ perl -we 'print ("." x 5)."foo";'
    print (...) interpreted as function at -e line 1.
    Useless use of concatenation (.) or string in void context at -e line 1.
    .....

    To obtain happiness, add more parentheses or use the unary plus operator:
    $ perl -we 'print(("." x 5)."foo");'
    .....foo
    $ perl -we 'print +("." x 5)."foo";'
    .....foo

    --
    Glenn Jackman
    NCF Sysadmin
    ca
    Glenn Guest

  6. #6

    Default Re: Oddity with the x and . operators

    Dan Wilga <edu> wrote: 
     
     
     
     
     
     
     

    If you get only that, then you're not using warnings.
     

    One of the warnings is...
    print (...) interpreted as function at -e line 1.

    Perldiag mentions..
    %s (...) interpreted as function
    (W) You've run afoul of the rule that says that any list
    operator followed by parentheses turns into a function,
    with all the list operators arguments found inside the
    parentheses. See the section on Terms and List
    Operators (Leftward) in the perlop manpage.

    Which would take you to perlop which explains this in that section.
     
     

    Right. You got rid of the leading "(" immediately after the print, so
    it's not interpreted as the entire argument to the function. There are
    several other rewrites you could do.
     

    That's not what the problem is.

    --
    Darren Dunham com
    Unix System Administrator Taos - The SysAdmin Company
    Got some Dr Pepper? San Francisco, CA bay area
    < This line left intentionally blank to confuse you. >
    Darren Guest

  7. #7

    Default Re: Oddity with the x and . operators

    Nevermind. I found the answer to my question just a few paragraphs down
    in perlop:

    "If any list operator (print(), etc.) or any unary operator (chdir(),
    etc.) is followed by a left parenthesis as the next token, the operator
    and arguments within parentheses are taken to be of highest precedence,
    just like a normal function call. Examples:"

    There's also a warning in perlfunc:

    "Also be careful not to follow the print keyword with a left parenthesis
    unless you want the corresponding right parenthesis to terminate the
    arguments to the print--interpose a `+' or put parentheses around all
    the arguments."

    So the code:

    print ("." x 5)."foo";

    is being evaluated as:

    print("." x 5)

    and then the return value of the "print" is being concatenated with
    "foo" and discarded.

    So much of the way Perl works has become intuitive to me after using it
    for so long, but this one, I just don't know if I can ever accept it.
    (I'm not looking for an argument here, just stating that it seems
    unintuitive if you never use the return value from print.)

    --
    Dan Wilga edu
    ** Remove the -MUNGE in my address to reply **
    Dan Guest

  8. #8

    Default Re: Oddity with the x and . operators

    Dan Wilga <edu> wrote:
     


    That can happen when you do not enable warnings.

    (so you should enable them)

     


    You should always enable warnings when developing Perl code.

     


    It isn't (directly) discarded.

    It is concatentated with whatever print() returned (probably a 1)
    and the result of the concatenation is then discarded (void context).

     


    Or to any of these:

    print( ("." x 5) . "foo"); # parens around _entire_ arg list

    print "." x 5 . "foo";

    print +("." x 5) . "foo";

     


    The problem is not related to concatenation, the problem is
    related to print() (or _any_ function actually).

     


    Yes, but not-being-a-scalar is not your problem.

     


    Why would you expect that?

    (a list in scalar context does NOT evaluate to the number of
    elements in the list. In fact, a list cannot exist in scalar
    context at all!)


    See this thread for what is really causing your problem (wrapped):

    http://groups.google.com/groups?
    as_umsgid=slrnatq036.2q2.tadmc%40magna.augustmail. com


    --
    Tad McClellan SGML consulting
    com Perl programming
    Fort Worth, Texas
    Tad Guest

  9. #9

    Default print (...) interpreted as function (was Re: Oddity with the x and . operators)

    Darren Dunham (taos.com) wrote on MMMDCCIV September
    MCMXCIII in <URL:news:IzBlb.5669$news.prodigy.com>:
    !!
    !! One of the warnings is...
    !! print (...) interpreted as function at -e line 1.

    <rant>

    This is one of the most useless and annoying warnings there is.
    I find it so annoying that I patched my perl and ripped it out.

    Pop quiz, which of the following will emit the warning?
    Answer after the formfeed.

    1: print(3 + 4) * 5;


    2: print (3 + 4) * 5;


    3: if (1) {
    print ("Hello")
    }


    4: print (")");


    5: {
    print (3), next if 1;
    }


    6: {
    print(3), "next" if 1;
    }




    Answers: it gives the warning in the cases 3, 4 and 5, and doesn't
    emit the warning in 1, 2 and 6. However, the cases 3, 4, and 5 are
    *correct*, while the cases 1, 2 and 6 have problems.

    It got *all* cases wrong.

    Luckily(?) this test is only done with print, printf and sort.
    It's thought that accidently parsing it as a function will only
    happen with these three functions, but never with other functions.

    </rant>


    Abigail
    --
    perl -wle 'print prototype sub "Just another Perl Hacker" {};'
    Abigail Guest

Similar Threads

  1. Date oddity in Acrobat, default page size oddity
    By Matt_Nelson@adobeforums.com in forum Adobe Acrobat Macintosh
    Replies: 3
    Last Post: November 14th, 03:35 PM
  2. gsub oddity?
    By Ralph in forum Ruby
    Replies: 7
    Last Post: January 23rd, 08:41 AM
  3. Toolbox oddity
    By Callum Ferguson in forum Adobe Photoshop Elements
    Replies: 1
    Last Post: September 18th, 10:20 AM
  4. OE oddity
    By Dunphy in forum Windows XP/2000/ME
    Replies: 1
    Last Post: July 10th, 11:55 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139