FAQ
This is a plea to remove the 'print (...) interpreted as function'
warning.

Let's look at the rational for this warning. It's to warn programmers
that if they write:

print (3 + 4) * 2;

Perl adds 3 and 4, calls print with the result as argument, and multiplies
the result of the print with 2. Fair and square, but this unintentional
parsing can happen with all functions taking a list as argument, not just
print. However, only 'print' and 'printf' can have this warning triggered,
with other functions are save.

But it gets more special. The warning is only triggered if there is
exactly one space between 'print' and the opening parenthesis.

print(3 + 4) * 2; # No 'interpreted as function' warning.
print (3 + 4) * 2; # 'interpreted as function' warning.
print (3 + 4) * 2; # No 'interpreted as function' warning.

The disadvantage of this warning is that it is also triggered at
perfectly valid code like:

print (3);

Therefore, I suggest we remove this warning, specially since code like:

print (3 + 4) * 2;

already issues a warning "Useless use of multiplication (*) in void context",
regardless of the amount of whitespace between 'print' and the opening
parenthesis.


Abigail

Search Discussions

  • Rafael Garcia-Suarez at Sep 1, 2003 at 1:40 pm

    Abigail wrote:
    This is a plea to remove the 'print (...) interpreted as function'
    warning.
    I tend to agree.
    Let's look at the rational for this warning. It's to warn programmers
    that if they write:

    print (3 + 4) * 2;

    Perl adds 3 and 4, calls print with the result as argument, and multiplies
    the result of the print with 2. Fair and square, but this unintentional
    parsing can happen with all functions taking a list as argument, not just
    print. However, only 'print' and 'printf' can have this warning triggered,
    with other functions are save.
    No, there's also sort :

    $ perl -wle 'sort (1)*2'
    sort (...) interpreted as function at -e line 1.
    Useless use of sort in scalar context at -e line 1.
    Useless use of multiplication (*) in void context at -e line 1.
    Use of uninitialized value in multiplication (*) at -e line 1.
    But it gets more special. The warning is only triggered if there is
    exactly one space between 'print' and the opening parenthesis.
    As says toke.c:6009 in bleadperl :

    if (*s == ' ' && s[1] == '(') { /* XXX gotta be a better way */
  • Michael G Schwern at Sep 2, 2003 at 12:12 am

    On Mon, Sep 01, 2003 at 02:57:29PM +0200, Abigail wrote:
    This is a plea to remove the 'print (...) interpreted as function'
    warning.

    Let's look at the rational for this warning. It's to warn programmers
    that if they write:

    print (3 + 4) * 2;

    Perl adds 3 and 4, calls print with the result as argument, and multiplies
    the result of the print with 2. Fair and square, but this unintentional
    parsing can happen with all functions taking a list as argument, not just
    print. However, only 'print' and 'printf' can have this warning triggered,
    with other functions are save.
    I've triggered this warning many a time, and every time it was valid and
    saved a lot of head scratching. I'd say to leave it in.

    While its true this precedence confusion could happen with any function, it
    typically only happens with print since print is more often used without
    parens and with complex statements than any other.

    But it gets more special. The warning is only triggered if there is
    exactly one space between 'print' and the opening parenthesis.

    print(3 + 4) * 2; # No 'interpreted as function' warning.
    print (3 + 4) * 2; # 'interpreted as function' warning.
    print (3 + 4) * 2; # No 'interpreted as function' warning.
    I'd say that the first should not warn, as its a fair guess to say the
    user is intentionally trying to use print as a function, while 2 and 3
    should warn since the user very likely made a mistake. If there's a bug
    to fix, that's it.

    The disadvantage of this warning is that it is also triggered at
    perfectly valid code like:

    print (3);
    I'd argue that this is unlikely. Personally, I've never come across it.
    I'd also argue that the "function (args)" style is uncommon. "print (arg)"
    is even less common. I'd be interested to see an example of it in the wild.

    Therefore, I suggest we remove this warning, specially since code like:

    print (3 + 4) * 2;

    already issues a warning "Useless use of multiplication (*) in void context",
    regardless of the amount of whitespace between 'print' and the opening
    some_func() || print (3 + 4) * 2;


    --
    Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/
    Death? Its like being on holiday with a group of Germans.
  • Garry Williams at Sep 2, 2003 at 6:26 am

    On Mon, Sep 01, 2003 at 17:11:42 -0700, Michael G Schwern wrote:
    On Mon, Sep 01, 2003 at 02:57:29PM +0200, Abigail wrote:
    [snip]
    The disadvantage of this warning is that it is also triggered at
    perfectly valid code like:

    print (3);
    I'd argue that this is unlikely. Personally, I've never come across
    it. I'd also argue that the "function (args)" style is uncommon.
    "print (arg)" is even less common. I'd be interested to see an
    example of it in the wild.
    Well, I happen to work with a fellow who _always_ types a single space
    before the opening paren in a function call. I don't know where he
    picked up the habit, but I always notice it when I come behind him.

    He also seems to use parentheses for almost all Perl built-ins.

    The good news is that he never uses parentheses with print() or
    printf(). Maybe the warning has shaped that behavior. :-)

    --
    Garry Williams, Zvolve Systems, Inc., +1 770 813-4934
  • Abigail at Sep 2, 2003 at 7:07 am

    On Mon, Sep 01, 2003 at 05:11:42PM -0700, Michael G Schwern wrote:
    On Mon, Sep 01, 2003 at 02:57:29PM +0200, Abigail wrote:
    This is a plea to remove the 'print (...) interpreted as function'
    warning.

    Let's look at the rational for this warning. It's to warn programmers
    that if they write:

    print (3 + 4) * 2;

    Perl adds 3 and 4, calls print with the result as argument, and multiplies
    the result of the print with 2. Fair and square, but this unintentional
    parsing can happen with all functions taking a list as argument, not just
    print. However, only 'print' and 'printf' can have this warning triggered,
    with other functions are save.
    I've triggered this warning many a time, and every time it was valid and
    saved a lot of head scratching. I'd say to leave it in.

    While its true this precedence confusion could happen with any function, it
    typically only happens with print since print is more often used without
    parens and with complex statements than any other.
    But I bet there's a positive correlation between the existence of the
    warning and the none appearance of the parenthesis after print.
    But it gets more special. The warning is only triggered if there is
    exactly one space between 'print' and the opening parenthesis.

    print(3 + 4) * 2; # No 'interpreted as function' warning.
    print (3 + 4) * 2; # 'interpreted as function' warning.
    print (3 + 4) * 2; # No 'interpreted as function' warning.
    I'd say that the first should not warn, as its a fair guess to say the
    user is intentionally trying to use print as a function, while 2 and 3
    should warn since the user very likely made a mistake. If there's a bug
    to fix, that's it.
    That argument doesn't make any sense to me.
    The disadvantage of this warning is that it is also triggered at
    perfectly valid code like:

    print (3);
    I'd argue that this is unlikely. Personally, I've never come across it.
    I'd also argue that the "function (args)" style is uncommon. "print (arg)"
    is even less common. I'd be interested to see an example of it in the wild.
    Are you saying that using parenthesis around function arguments is
    uncommon? Or that using a space between the function name and the
    opening paren is uncommon? Well, you do it yourself, since you write:
    I've triggered this warning many a time
    and that warning *won't* get triggered unless you use a space between the
    function name and the parenthesis.

    I leave off the parenthesis if I can, but if I have to use parenthesis
    in a function call I *always* put a space between the function name
    and the opening parenthesis.



    Abigail
  • Michael G Schwern at Sep 2, 2003 at 8:39 am

    On Tue, Sep 02, 2003 at 09:06:38AM +0200, Abigail wrote:
    I've triggered this warning many a time, and every time it was valid and
    saved a lot of head scratching. I'd say to leave it in.

    While its true this precedence confusion could happen with any function, it
    typically only happens with print since print is more often used without
    parens and with complex statements than any other.
    But I bet there's a positive correlation between the existence of the
    warning and the none appearance of the parenthesis after print.
    I wouldn't. We teach print as: print "Some string" almost never as
    print("Some string").

    But it gets more special. The warning is only triggered if there is
    exactly one space between 'print' and the opening parenthesis.

    print(3 + 4) * 2; # No 'interpreted as function' warning.
    print (3 + 4) * 2; # 'interpreted as function' warning.
    print (3 + 4) * 2; # No 'interpreted as function' warning.
    I'd say that the first should not warn, as its a fair guess to say the
    user is intentionally trying to use print as a function, while 2 and 3
    should warn since the user very likely made a mistake. If there's a bug
    to fix, that's it.
    That argument doesn't make any sense to me.
    There's two parts.

    The fact that the warning does not trigger with more than one space, yet does
    with one space is definately a bug/inconsistency and should be fixed.

    The fact that there's no warning when there's no space seems deliberate
    because its unlikely that:

    print(3 + 4) * 2;

    really meant

    print((3 + 4) * 2);

    because its rare for one to write:

    function(expression + expression) * expression;

    and expect

    function((expression + expression) * expression));

    That lack of space is fairly indicative of the intent of the user.

    The disadvantage of this warning is that it is also triggered at
    perfectly valid code like:

    print (3);
    I'd argue that this is unlikely. Personally, I've never come across it.
    I'd also argue that the "function (args)" style is uncommon. "print (arg)"
    is even less common. I'd be interested to see an example of it in the wild.
    Are you saying that using parenthesis around function arguments is
    uncommon? Or that using a space between the function name and the
    opening paren is uncommon? Well, you do it yourself, since you write:
    That the space between the opening paren is uncommon when the parens are
    there *merely to make the function's arguments explicit*.

    func ($foo, $bar); # uncommon
    func($foo, $bar); # common

    I've triggered this warning many a time
    and that warning *won't* get triggered unless you use a space between the
    function name and the parenthesis.
    Yes. This makes sense to me. I don't write:

    print(3 + 4) * 2;

    and expect

    print((3 + 4) * 2);

    That much is clear to me just from the spacing. But I will make the mistake
    of writing

    print (3 + 4) * 2;

    and expect it to mean

    print((3 + 4) * 2);

    partially because the spacing and partially because I don't think of print
    as a normal function. I have it somewhere in my brain that its special.
    This is exactly what the warning is protecting against. The user forgetting
    that print follows normal function precedence rules.

    I leave off the parenthesis if I can, but if I have to use parenthesis
    in a function call I *always* put a space between the function name
    and the opening parenthesis.
    You're weird. :)

    My final word on this is that this warning has saved me many times and
    continues to do so even after years of writing Perl. There's something
    special about print and parens in my brain.


    --
    Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/
  • H.Merijn Brand at Sep 2, 2003 at 9:07 am

    On Tue 02 Sep 2003 02:11, Michael G Schwern wrote:
    On Mon, Sep 01, 2003 at 02:57:29PM +0200, Abigail wrote:
    This is a plea to remove the 'print (...) interpreted as function'
    warning.
    FWIW I agree.
    Let's look at the rational for this warning. It's to warn programmers
    that if they write:

    print (3 + 4) * 2;

    Perl adds 3 and 4, calls print with the result as argument, and multiplies
    the result of the print with 2. Fair and square, but this unintentional
    parsing can happen with all functions taking a list as argument, not just
    print. However, only 'print' and 'printf' can have this warning triggered,
    with other functions are save.
    I've triggered this warning many a time, and every time it was valid and
    saved a lot of head scratching. I'd say to leave it in.

    While its true this precedence confusion could happen with any function, it
    typically only happens with print since print is more often used without
    parens and with complex statements than any other.
    Yep. True. And most of us know to put a plus, or "", in front of the
    expression to make this warning go away and use print as one meant
    But it gets more special. The warning is only triggered if there is
    exactly one space between 'print' and the opening parenthesis.

    print(3 + 4) * 2; # No 'interpreted as function' warning.
    print (3 + 4) * 2; # 'interpreted as function' warning.
    print (3 + 4) * 2; # No 'interpreted as function' warning.
    I'd say that the first should not warn, as its a fair guess to say the
    user is intentionally trying to use print as a function, while 2 and 3
    should warn since the user very likely made a mistake. If there's a bug
    to fix, that's it.
    I agree for case 1 and 3. Since IMHO a function and its opening paren should
    *always* be sparated by a space, I personally would remove the warning for

    print\s\s+\(

    only
    The disadvantage of this warning is that it is also triggered at
    perfectly valid code like:

    print (3);
    I'd argue that this is unlikely. Personally, I've never come across it.
    m/expression/ and print (3), next;

    *very* useful, and often used.
    I'd also argue that the "function (args)" style is uncommon.
    What do you mean by that? A separating space? It should be obligatory. *ALL*
    my code (perl, C, 4GL, ...) does that.
    "print (arg)" is even less common.
    I'd be interested to see an example of it in the wild.
    As shown above
    Therefore, I suggest we remove this warning, specially since code like:

    print (3 + 4) * 2;

    already issues a warning "Useless use of multiplication (*) in void context",
    regardless of the amount of whitespace between 'print' and the opening
    some_func() || print (3 + 4) * 2;
    some_func () or print 2 * (3 + 4);

    --
    H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
    using perl-5.6.1, 5.8.0, & 5.9.x, and 806 on HP-UX 10.20 & 11.00, 11i,
    AIX 4.3, SuSE 8.2, and Win2k. http://www.cmve.net/~merijn/
    http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
    send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org
  • Michael G Schwern at Sep 2, 2003 at 9:58 am

    On Tue, Sep 02, 2003 at 11:07:20AM +0200, H.Merijn Brand wrote:
    I've triggered this warning many a time, and every time it was valid and
    saved a lot of head scratching. I'd say to leave it in.

    While its true this precedence confusion could happen with any function, it
    typically only happens with print since print is more often used without
    parens and with complex statements than any other.
    Yep. True. And most of us know to put a plus, or "", in front of the
    expression to make this warning go away and use print as one meant
    If we remove the warning, how do I find the problem and add the +?

    I'd also argue that the "function (args)" style is uncommon.
    What do you mean by that? A separating space? It should be obligatory. *ALL*
    my code (perl, C, 4GL, ...) does that.
    I contend you're weird, too. :)


    --
    Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/
    But I wore the juice!
  • H.Merijn Brand at Sep 2, 2003 at 10:02 am

    On Tue 02 Sep 2003 11:57, Michael G Schwern wrote:
    On Tue, Sep 02, 2003 at 11:07:20AM +0200, H.Merijn Brand wrote:
    I've triggered this warning many a time, and every time it was valid and
    saved a lot of head scratching. I'd say to leave it in.

    While its true this precedence confusion could happen with any function, it
    typically only happens with print since print is more often used without
    parens and with complex statements than any other.
    Yep. True. And most of us know to put a plus, or "", in front of the
    expression to make this warning go away and use print as one meant
    If we remove the warning, how do I find the problem and add the +?
    I suggest ftp://download.xs4all.nl/pub/mirror/CPAN/modules/by-module/Devel/Devel-ptkdb-1.1086.tar.gz
    <ducking>
    I'd also argue that the "function (args)" style is uncommon.
    What do you mean by that? A separating space? It should be obligatory. *ALL*
    my code (perl, C, 4GL, ...) does that.
    I contend you're weird, too. :)
    nod, nod, nod.

    --
    H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
    using perl-5.6.1, 5.8.0, & 5.9.x, and 806 on HP-UX 10.20 & 11.00, 11i,
    AIX 4.3, SuSE 8.2, and Win2k. http://www.cmve.net/~merijn/
    http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
    send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org
  • Russ Allbery at Sep 2, 2003 at 5:54 pm

    Michael G Schwern writes:
    On Tue, Sep 02, 2003 at 11:07:20AM +0200, H.Merijn Brand wrote:

    What do you mean by that? A separating space? It should be
    obligatory. *ALL* my code (perl, C, 4GL, ...) does that.
    I contend you're weird, too. :)
    I do it in Perl and not in other languages. It makes the list explicit.
    So add me to the growing set of weird people.

    Note that a space before the parenthesis is also the GNU coding style, and
    whatever one might think of that style (I'm not particularly fond of it
    myself), there's a very large body of code written in it, some of which is
    in Perl.

    --
    Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
  • Orton, Yves at Sep 2, 2003 at 10:17 am

    I contend you're weird, too. :)
    nod, nod, nod.
    We used to say in school that "weird is wonderful!"

    Yves
  • Abigail at Sep 4, 2003 at 1:51 pm

    On Mon, Sep 01, 2003 at 02:57:29PM +0200, Abigail wrote:
    This is a plea to remove the 'print (...) interpreted as function'
    warning.

    Since only one person objected, I've made a patch against blead_perl
    that removes this warning.

    The patch works well with 5.8.1-to-be too.


    Abigail


    diff -ru perl-5.9.0/pod/perldiag.pod perl-5.9.0.no-warning/pod/perldiag.pod
    --- perl-5.9.0/pod/perldiag.pod Tue Sep 2 18:52:23 2003
    +++ perl-5.9.0.no-warning/pod/perldiag.pod Thu Sep 4 15:39:28 2003
    @@ -1834,13 +1834,6 @@
    <-- HERE shows in the regular expression about where the problem was
    discovered.

    -=item %s (...) interpreted as function
    -
    -(W syntax) 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
    -L<perlop/Terms and List Operators (Leftward)>.
    -
    =item Invalid %s attribute: %s

    The indicated attribute for a subroutine or variable was not recognized
    diff -ru perl-5.9.0/pod/perlfunc.pod perl-5.9.0.no-warning/pod/perlfunc.pod
    --- perl-5.9.0/pod/perlfunc.pod Wed Sep 3 00:38:15 2003
    +++ perl-5.9.0.no-warning/pod/perlfunc.pod Thu Sep 4 15:40:44 2003
    @@ -42,12 +42,6 @@
    print +(1+2)+4; # Prints 7.
    print ((1+2)+4); # Prints 7.

    -If you run Perl with the B<-w> switch it can warn you about this. For
    -example, the third line above produces:
    -
    - print (...) interpreted as function at - line 1.
    - Useless use of integer addition in void context at - line 1.
    -
    A few functions take no arguments at all, and therefore work as neither
    unary nor list operators. These include such functions as C<time>
    and C<endpwent>. For example, C<time+86_400> always means
    diff -ru perl-5.9.0/t/lib/warnings/toke perl-5.9.0.no-warning/t/lib/warnings/toke
    --- perl-5.9.0/t/lib/warnings/toke Thu Jul 3 09:47:53 2003
    +++ perl-5.9.0.no-warning/t/lib/warnings/toke Thu Sep 4 14:04:03 2003
    @@ -52,11 +52,6 @@
    Possible attempt to put comments in qw() list
    @a = qw(a b # c) ;

    - %s (...) interpreted as function
    - print ("")
    - printf ("")
    - sort ("")
    -
    Ambiguous use of %c{%s%s} resolved to %c%s%s
    $a = ${time[2]}
    $a = ${time{2}}
    @@ -278,42 +273,6 @@
    Possible attempt to put comments in qw() list at - line 3.
    ########
    # toke.c
    -use warnings 'syntax' ;
    -print ("")
    -EXPECT
    -print (...) interpreted as function at - line 3.
    -########
    -# toke.c
    -no warnings 'syntax' ;
    -print ("")
    -EXPECT
    -
    -########
    -# toke.c
    -use warnings 'syntax' ;
    -printf ("")
    -EXPECT
    -printf (...) interpreted as function at - line 3.
    -########
    -# toke.c
    -no warnings 'syntax' ;
    -printf ("")
    -EXPECT
    -
    -########
    -# toke.c
    -use warnings 'syntax' ;
    -sort ("")
    -EXPECT
    -sort (...) interpreted as function at - line 3.
    -########
    -# toke.c
    -no warnings 'syntax' ;
    -sort ("")
    -EXPECT
    -
    -########
    -# toke.c
    use warnings 'ambiguous' ;
    $a = ${time[2]};
    no warnings 'ambiguous' ;
    diff -ru perl-5.9.0/toke.c perl-5.9.0.no-warning/toke.c
    --- perl-5.9.0/toke.c Tue Aug 26 08:35:32 2003
    +++ perl-5.9.0.no-warning/toke.c Thu Sep 4 14:13:10 2003
    @@ -6006,22 +6006,6 @@
    {
    char *w;

    - if (*s == ' ' && s[1] == '(') { /* XXX gotta be a better way */
    - if (ckWARN(WARN_SYNTAX)) {
    - int level = 1;
    - for (w = s+2; *w && level; w++) {
    - if (*w == '(')
    - ++level;
    - else if (*w == ')')
    - --level;
    - }
    - if (*w)
    - for (; *w && isSPACE(*w); w++) ;
    - if (!*w || !strchr(";|})]oaiuw!=", *w)) /* an advisory hack only... */
    - Perl_warner(aTHX_ packWARN(WARN_SYNTAX),
    - "%s (...) interpreted as function",name);
    - }
    - }
    while (s < PL_bufend && isSPACE(*s))
    s++;
    if (*s == '(')
  • Yitzchak Scott-Thoennes at Sep 4, 2003 at 11:58 pm

    On Thu, Sep 04, 2003 at 03:50:12PM +0200, Abigail wrote:
    On Mon, Sep 01, 2003 at 02:57:29PM +0200, Abigail wrote:
    This is a plea to remove the 'print (...) interpreted as function'
    warning.

    Since only one person objected, I've made a patch against blead_perl
    that removes this warning.
    ++$objections
  • H.Merijn Brand at Sep 5, 2003 at 6:22 am

    On Fri 05 Sep 2003 01:57, Yitzchak Scott-Thoennes wrote:
    On Thu, Sep 04, 2003 at 03:50:12PM +0200, Abigail wrote:
    On Mon, Sep 01, 2003 at 02:57:29PM +0200, Abigail wrote:
    This is a plea to remove the 'print (...) interpreted as function'
    warning.

    Since only one person objected, I've made a patch against blead_perl
    that removes this warning.
    ++$objections
    Would $objections-- have any value here? <duck>

    I now have heard both sides of the story. The more `advanced' the programmer
    is, the less likely it is that he/she (Hi Wendy :) wants/requires this warning

    Though I would /personally/ like this warning gone, and I agree with the
    arguments Abigail gave in the first objecting proposal (inconsistency and all
    such), I can not stand behind the point that "since only one person objected"
    would be good enough a reason to remove a warning.

    There were also just a few --$objections, but the majority kept silence.

    There's no harm in proposing the patch, but in this case, I'd like to hear
    Hugo's opnion. I for sure will not burn my hands in submitting this patch.

    --
    H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
    using perl-5.6.1, 5.8.0, & 5.9.x, and 806 on HP-UX 10.20 & 11.00, 11i,
    AIX 4.3, SuSE 8.2, and Win2k. http://www.cmve.net/~merijn/
    http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
    send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org
  • Tassilo von Parseval at Sep 5, 2003 at 7:56 am

    On Fri, Sep 05, 2003 at 08:21:24AM +0200 H.Merijn Brand wrote:
    On Fri 05 Sep 2003 01:57, Yitzchak Scott-Thoennes wrote:
    On Thu, Sep 04, 2003 at 03:50:12PM +0200, Abigail wrote:

    Since only one person objected, I've made a patch against blead_perl
    that removes this warning.
    ++$objections
    Would $objections-- have any value here? <duck>

    I now have heard both sides of the story. The more `advanced' the programmer
    is, the less likely it is that he/she (Hi Wendy :) wants/requires this warning

    Though I would /personally/ like this warning gone, and I agree with the
    arguments Abigail gave in the first objecting proposal (inconsistency and all
    such), I can not stand behind the point that "since only one person objected"
    would be good enough a reason to remove a warning.

    There were also just a few --$objections, but the majority kept silence.
    As it currently is, we have two warnings, right?

    print (...) interpreted as function at ...
    Useless use of <BLA> in void context at ...

    Is there a case where only the first of the above two is triggered? I
    wasn't able to come up with one, but maybe there is.

    I think if these two warnings always come in pairs, we don't need the
    first one any longer. In the other case we should perhaps leave it as it
    is. I know that I often triggered it (and perl was so far always right
    with warning me).

    Tassilo
    --
    $_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
    pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
    $_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
  • Abigail at Sep 5, 2003 at 8:06 am

    On Fri, Sep 05, 2003 at 09:53:36AM +0200, Tassilo von Parseval wrote:

    As it currently is, we have two warnings, right?

    print (...) interpreted as function at ...
    Useless use of <BLA> in void context at ...

    Is there a case where only the first of the above two is triggered? I
    wasn't able to come up with one, but maybe there is.
    $foo and print ($bar), next;
    I think if these two warnings always come in pairs, we don't need the
    first one any longer. In the other case we should perhaps leave it as it
    is. I know that I often triggered it (and perl was so far always right
    with warning me).

    I've often triggered it as well, and perl has always been wrong.


    Abigail
  • Martyn J. Pearce at Sep 5, 2003 at 8:50 am

    On Fri, Sep 05, 2003 at 10:06:03AM +0200, Abigail wrote:
    On Fri, Sep 05, 2003 at 09:53:36AM +0200, Tassilo von Parseval wrote:
    Is there a case where only the first of the above two is triggered? I
    wasn't able to come up with one, but maybe there is.
    $foo and print ($bar), next;
    Even simpler (and more likely from beginners):

    perl -we 'print (3)'

    If I had a cent for the number of times someone has asked me what it's
    blethering on about...

    Moreover, the spuriousness of this is oft-cited as a reason people don't
    enable warnings. Whilst try I try to encourage people *to* use warnings, in
    this respect, I can hardly blame them...

    Mx.
  • H.Merijn Brand at Sep 5, 2003 at 11:13 am

    On Fri 05 Sep 2003 10:50, "Martyn J. Pearce" wrote:
    On Fri, Sep 05, 2003 at 10:06:03AM +0200, Abigail wrote:
    On Fri, Sep 05, 2003 at 09:53:36AM +0200, Tassilo von Parseval wrote:
    Is there a case where only the first of the above two is triggered? I
    wasn't able to come up with one, but maybe there is.
    $foo and print ($bar), next;
    Even simpler (and more likely from beginners):

    perl -we 'print (3)'
    The quest here was where print *needed* the paren's in order to function as
    expected, but still got the (here wrong) warning. Your example could easily do
    without the parens, but still falls in the category warning on perfectly valid
    code.
    If I had a cent for the number of times someone has asked me what it's
    blethering on about...

    Moreover, the spuriousness of this is oft-cited as a reason people don't
    enable warnings. Whilst try I try to encourage people *to* use warnings, in
    this respect, I can hardly blame them...

    Mx.
    --
    H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
    using perl-5.6.1, 5.8.0, & 5.9.x, and 806 on HP-UX 10.20 & 11.00, 11i,
    AIX 4.3, SuSE 8.2, and Win2k. http://www.cmve.net/~merijn/
    http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
    send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org
  • Martyn J. Pearce at Sep 5, 2003 at 12:10 pm

    On Fri, Sep 05, 2003 at 01:13:36PM +0200, H.Merijn Brand wrote:
    On Fri 05 Sep 2003 10:50, "Martyn J. Pearce" wrote:
    Even simpler (and more likely from beginners):

    perl -we 'print (3)'
    The quest here was where print *needed* the paren's in order to function as
    expected, but still got the (here wrong) warning. Your example could easily
    do without the parens, but still falls in the category warning on perfectly
    valid code.
    Quite true --- but the caveat that you wanted an example there needed the
    parens to function as expected was not clear frmo the requesting email :-)

    Mx.
  • Tassilo von Parseval at Sep 5, 2003 at 9:14 am

    On Fri, Sep 05, 2003 at 10:06:03AM +0200 Abigail wrote:
    On Fri, Sep 05, 2003 at 09:53:36AM +0200, Tassilo von Parseval wrote:

    As it currently is, we have two warnings, right?

    print (...) interpreted as function at ...
    Useless use of <BLA> in void context at ...

    Is there a case where only the first of the above two is triggered? I
    wasn't able to come up with one, but maybe there is.
    $foo and print ($bar), next;
    Ah, but in this case the warning is useless. What I meant to ask was:
    Is there a case where only the 'print interpreted as function' warning
    is triggered and where a second set of parens is needed to make the
    statement behave as intended?

    My assumption namely is that the warning is only justified if _both_
    warnings show up...in which case we can just as easily have only one of
    them. If only the 'interpreted as function' thing shows up, we can be
    sure that anything that follows the argument-list has no return-value
    and therefore cannot contribute to the string printed. Am I right?
    I think if these two warnings always come in pairs, we don't need the
    first one any longer. In the other case we should perhaps leave it as it
    is. I know that I often triggered it (and perl was so far always right
    with warning me).

    I've often triggered it as well, and perl has always been wrong.
    I am with you on that. Let's remove this thing.

    Tassilo
    --
    $_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
    pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
    $_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
  • Michael G Schwern at Sep 11, 2003 at 5:28 am

    On Fri, Sep 05, 2003 at 10:06:03AM +0200, Abigail wrote:
    I've often triggered it as well, and perl has always been wrong.
    I have a sneaking suspicion that whether your for or against this warning
    is determined by whether you write "func(foo)" or "func (foo)".

    Anyhow, here's a recent post from a user on vmsperl that would find this
    warning useful.
    http://nntp.x.perl.org/group/perl.vmsperl/12005


    --
    Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/
    Nature is pissed.
    http://www.unamerican.com/
  • Ronald J Kimball at Sep 5, 2003 at 1:01 pm

    On Fri, Sep 05, 2003 at 09:53:36AM +0200, Tassilo von Parseval wrote:

    As it currently is, we have two warnings, right?

    print (...) interpreted as function at ...
    Useless use of <BLA> in void context at ...

    Is there a case where only the first of the above two is triggered? I
    wasn't able to come up with one, but maybe there is.
    Yes, any case where the remainder of the expression is not in void context,
    of course.

    sub foo {
    print ($_[0] + 1), "!\n";
    }

    foo(0);


    Ronald
  • H.Merijn Brand at Sep 5, 2003 at 1:09 pm

    On Fri 05 Sep 2003 15:00, Ronald J Kimball wrote:
    On Fri, Sep 05, 2003 at 09:53:36AM +0200, Tassilo von Parseval wrote:

    As it currently is, we have two warnings, right?

    print (...) interpreted as function at ...
    Useless use of <BLA> in void context at ...

    Is there a case where only the first of the above two is triggered? I
    wasn't able to come up with one, but maybe there is.
    Yes, any case where the remainder of the expression is not in void context,
    of course.

    sub foo {
    print ($_[0] + 1), "!\n";
    Since you can drop the parens here, a better example would be

    lt02:/tmp 109 > cat xx.pl
    sub foo
    {
    print (substr $_[0], 4), 15;
    } # foo

    foo "bummerr!";
    lt02:/tmp 110 > perl -lw xx.pl
    print (...) interpreted as function at xx.pl line 3.
    err!
    lt02:/tmp 111 >

    where you need the parens to withhold the remaining arguments to be taken by
    substr for which the arguments are optional
    }

    foo(0);
    --
    H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
    using perl-5.6.1, 5.8.0, & 5.9.x, and 806 on HP-UX 10.20 & 11.00, 11i,
    AIX 4.3, SuSE 8.2, and Win2k. http://www.cmve.net/~merijn/
    http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
    send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org
  • Michael G Schwern at Sep 11, 2003 at 5:28 am

    On Fri, Sep 05, 2003 at 09:53:36AM +0200, Tassilo von Parseval wrote:
    As it currently is, we have two warnings, right?

    print (...) interpreted as function at ...
    Useless use of <BLA> in void context at ...

    Is there a case where only the first of the above two is triggered? I
    wasn't able to come up with one, but maybe there is.

    I think if these two warnings always come in pairs, we don't need the
    first one any longer. In the other case we should perhaps leave it as it
    is. I know that I often triggered it (and perl was so far always right
    with warning me).
    The trouble with relying on the void context warning is it doesn't tell you
    what you *really* did wrong. Folks will stare at:

    print (2 + 3) * 4;

    and try to figure out where the void context is.


    --
    Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/
    WOOHOO! I'm going to Disneyland!
    http://www.goats.com/archive/980805.html
  • Michael G Schwern at Sep 11, 2003 at 5:27 am

    On Fri, Sep 05, 2003 at 08:21:24AM +0200, H.Merijn Brand wrote:
    I now have heard both sides of the story. The more `advanced' the programmer
    is, the less likely it is that he/she (Hi Wendy :) wants/requires this warning
    I find that warning quite useful still. What are you trying to say,
    Merijn? ;)


    --
    Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/
    I can't give you any knowledge, but who wants candy??
    -- http://www.angryflower.com/drawin.gif
  • H.Merijn Brand at Sep 11, 2003 at 8:48 am

    On Fri 05 Sep 2003 18:25, Michael G Schwern wrote:
    On Fri, Sep 05, 2003 at 08:21:24AM +0200, H.Merijn Brand wrote:
    I now have heard both sides of the story. The more `advanced' the programmer
    is, the less likely it is that he/she (Hi Wendy :) wants/requires this warning
    I find that warning quite useful still. What are you trying to say,
    Merijn? ;)
    That for *many* users this warning /might/ be very useful, and for other users
    (maybe also many) this warning might come as a complete surprise, but that the
    `advanced' users will recognize the reason *much* faster than the less
    experienced users.

    Though I'm in Abigails camp here (the warning was issued many times, but it
    was *never* wrong), I still can live with that I have to use a plus, or a "",
    in front of the first paren, which opens a new problem: If someone else is to
    maintain my source later, and sees 'print "", (1 + 2) * 3;' it is not unlikely
    that he/she will remove that stupid looking empty string in front, and
    therewith releasing the bogus error^Wwarning.

    Personally - meaning not in the shoes of a pumpkin of any sort - I would
    remove the message, but thinking about the poor users that get this message
    when they need it, I'd leave it in.

    What IMHO needs to be removed is the inconsistency in leading whitespace. The
    warning should be issued regardless of how much white is between print and the
    opening paren. Not in the case of just one single space, which would be
    warning on the only correct way to call a function.

    --
    H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
    using perl-5.6.1, 5.8.0, & 5.9.x, and 806 on HP-UX 10.20 & 11.00, 11i,
    AIX 4.3, SuSE 8.2, and Win2k. http://www.cmve.net/~merijn/
    http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
    send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org
  • Michael G Schwern at Sep 11, 2003 at 11:40 am

    On Thu, Sep 11, 2003 at 10:48:49AM +0200, H.Merijn Brand wrote:
    Though I'm in Abigails camp here (the warning was issued many times, but it
    was *never* wrong), I still can live with that I have to use a plus, or a "",
    in front of the first paren, which opens a new problem: If someone else is to
    maintain my source later, and sees 'print "", (1 + 2) * 3;' it is not unlikely
    that he/she will remove that stupid looking empty string in front, and
    therewith releasing the bogus error^Wwarning.
    Well then don't use "" hackery, use +(...).

    What IMHO needs to be removed is the inconsistency in leading whitespace. The
    warning should be issued regardless of how much white is between print and the
    opening paren. Not in the case of just one single space, which would be
    warning on the only correct way to call a function.
    Agreed. Except on the "only correct way" bit. ;)


    --
    Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/
    Let me check my notes.
    http://www.sluggy.com
  • Abigail at Sep 11, 2003 at 11:49 am

    On Thu, Sep 11, 2003 at 04:40:00AM -0700, Michael G Schwern wrote:
    On Thu, Sep 11, 2003 at 10:48:49AM +0200, H.Merijn Brand wrote:
    Though I'm in Abigails camp here (the warning was issued many times, but it
    was *never* wrong), I still can live with that I have to use a plus, or a ""
    in front of the first paren, which opens a new problem: If someone else is t
    maintain my source later, and sees 'print "", (1 + 2) * 3;' it is not unlike
    that he/she will remove that stupid looking empty string in front, and
    therewith releasing the bogus error^Wwarning.
    Well then don't use "" hackery, use +(...).
    Yeah, I really enjoy explaining the '+' to new Perl students, and
    various Perl forums. Having to channel obscure magic to avoid Perl
    issuing warnings on common, legitimate code, doesn't do much for the
    image of Perl being a write-only voodoo language.

    OTOH, it does give Python zealots something to slap Perl users with
    when they start complaining about the significant white space in Python.
    What IMHO needs to be removed is the inconsistency in leading whitespace. Th
    warning should be issued regardless of how much white is between print and t
    opening paren. Not in the case of just one single space, which would be
    warning on the only correct way to call a function.
    Agreed. Except on the "only correct way" bit. ;)
    I wonder how long the warning will last if it's also issued when
    there's no white space following the 'print' keyword.


    Abigail
  • Michael G Schwern at Sep 11, 2003 at 12:00 pm

    On Thu, Sep 11, 2003 at 01:49:24PM +0200, Abigail wrote:
    I wonder how long the warning will last if it's also issued when
    there's no white space following the 'print' keyword.
    Not very long since the formatting of "print(2 + 3) * 5" makes the use of
    print as a function obvious enough. :)


    --
    Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/
    Carpe canem! Seize the dog! This cannot be right.
    -- The Critic
  • Abigail at Sep 11, 2003 at 12:09 pm

    On Thu, Sep 11, 2003 at 05:00:16AM -0700, Michael G Schwern wrote:
    On Thu, Sep 11, 2003 at 01:49:24PM +0200, Abigail wrote:
    I wonder how long the warning will last if it's also issued when
    there's no white space following the 'print' keyword.
    Not very long since the formatting of "print(2 + 3) * 5" makes the use of
    print as a function obvious enough. :)

    You still don't understand, do you?

    It will mean that the warning is also issued on "print(2 + 3)".

    My problem with the warning isn't that it issued on "print (2 + 3) * 5",
    but that it is also issued on "print (2 + 3)".



    Abigail
  • H.Merijn Brand at Sep 11, 2003 at 12:15 pm

    On Thu 11 Sep 2003 14:00, Michael G Schwern wrote:
    On Thu, Sep 11, 2003 at 01:49:24PM +0200, Abigail wrote:
    I wonder how long the warning will last if it's also issued when
    there's no white space following the 'print' keyword.
    Not very long since the formatting of "print(2 + 3) * 5" makes the use of
    print as a function obvious enough. :)
    Only for some. And not in one-liners, where we tend to omit as much whitespace
    as possible

    bev a5:/tmp 118 > cat xx
    I measured the following temperature:
    98.6F
    bev a5:/tmp 119 > perl -lne'/F/&&print($_-32)*(5/9),"C"' xx
    66.6

    Uh-oh, sooooo wrong

    bev a5:/tmp 120 > perl -wlne'/F/&&print($_-32)*(5/9),"C"' xx
    Useless use of multiplication (*) in void context at -e line 1.
    Useless use of a constant in void context at -e line 1.
    Argument "98.6F" isn't numeric in subtraction (-) at -e line 1, <> line 2.
    66.6
    bev a5:/tmp 121 > perl -wlne'/F/&&print+($_-32)*(5/9),"C"' xx
    Argument "98.6F" isn't numeric in subtraction (-) at -e line 1, <> line 2.
    37C
    bev a5:/tmp 122 >

    Now the answer is right. And you see the reason why I didn't want the -w in
    this one-liner in the first place. Much better examples are easy to think of I
    guess.

    --
    H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
    using perl-5.6.1, 5.8.0, & 5.9.x, and 806 on HP-UX 10.20 & 11.00, 11i,
    AIX 4.3, SuSE 8.2, and Win2k. http://www.cmve.net/~merijn/
    http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
    send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org
  • Michael G Schwern at Sep 11, 2003 at 9:01 pm

    On Thu, Sep 11, 2003 at 02:14:54PM +0200, H.Merijn Brand wrote:
    On Thu 11 Sep 2003 14:00, Michael G Schwern wrote:
    On Thu, Sep 11, 2003 at 01:49:24PM +0200, Abigail wrote:
    I wonder how long the warning will last if it's also issued when
    there's no white space following the 'print' keyword.
    Not very long since the formatting of "print(2 + 3) * 5" makes the use of
    print as a function obvious enough. :)
    Only for some. And not in one-liners, where we tend to omit as much whitespace
    as possible
    One-liners are their own little world.


    --
    Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/
    Thanks, applied. Or, ??????k@???????K^U
    as we Bulgarian EBCDIC users like to say.
    -- Jarkko Hietaniemi in <20020130074930.J2887@alpha.hut.fi>
  • David nicol at Sep 13, 2003 at 4:07 am

    On Thu, 2003-09-11 at 07:00, Michael G Schwern wrote:
    On Thu, Sep 11, 2003 at 01:49:24PM +0200, Abigail wrote:
    I wonder how long the warning will last if it's also issued when
    there's no white space following the 'print' keyword.
    Not very long since the formatting of "print(2 + 3) * 5" makes the use of
    print as a function obvious enough. :)

    { no warnings; print ((2 + 3) * 5) }

    We could gather statistics on whitespace occuring btn
    function names and argument lists in the current file and
    issue the warning depending on if the print call uses
    the wrong amount of WS. That is, in effect, maintain
    two tallies, WS_AFTER_FUNC_NAME and EXPLICIT_ARG_LISTS,
    ... in order to make Perl slightly more like Intercal.

    Which is absurd.

    Maybe the warning could be an additional hint that
    is produced when a "Useless use..." warning occurs
    within a C<print>?

    Instead of
    perl -wle 'print(2 + 3) * 5'
    Useless use of integer multiplication (*) in void context at -e line 1.
    5

    we would get
    perl -wle 'print(2 + 3) * 5'
    Useless use of integer multiplication (*) in void context at -e line 1.
    Check scope of print(...) arguments?
    5





    --
    David Nicol / kernel 2.6.0 is pretty whippy
  • H.Merijn Brand at Sep 11, 2003 at 11:54 am

    On Thu 11 Sep 2003 13:40, Michael G Schwern wrote:
    On Thu, Sep 11, 2003 at 10:48:49AM +0200, H.Merijn Brand wrote:
    Though I'm in Abigails camp here (the warning was issued many times, but it
    was *never* wrong), I still can live with that I have to use a plus, or a "",
    in front of the first paren, which opens a new problem: If someone else is to
    maintain my source later, and sees 'print "", (1 + 2) * 3;' it is not unlikely
    that he/she will remove that stupid looking empty string in front, and
    therewith releasing the bogus error^Wwarning.
    Well then don't use "" hackery, use +(...).
    Same problem. And it does look even more silly.
    Best workaround in above example

    print 3 * (1 + 2);

    but of course, that ain't always possible.

    --
    H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
    using perl-5.6.1, 5.8.0, & 5.9.x, and 806 on HP-UX 10.20 & 11.00, 11i,
    AIX 4.3, SuSE 8.2, and Win2k. http://www.cmve.net/~merijn/
    http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
    send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org
  • Kurt Starsinic at Sep 11, 2003 at 1:21 pm

    On Sep 11, Michael Schwern wrote:
    On Thu, Sep 11, 2003 at 10:48:49AM +0200, H.Merijn Brand wrote:
    Though I'm in Abigails camp here (the warning was issued many times, but it
    was *never* wrong), I still can live with that I have to use a plus, or a "",
    in front of the first paren, which opens a new problem: If someone else is to
    maintain my source later, and sees 'print "", (1 + 2) * 3;' it is not unlikely
    that he/she will remove that stupid looking empty string in front, and
    therewith releasing the bogus error^Wwarning.
    Well then don't use "" hackery, use +(...).
    Or ((...)...)

    That's what I always do. I don't think there are too many programmers
    who would be confused by that.

    - Kurt
  • Rafael Garcia-Suarez at Sep 11, 2003 at 1:35 pm
    Time to give my humble opinion on this long thread :

    the current "print (...)" warning is poorly implemented, and
    the comments in toke.c agree with me. I think it should be
    removed.

    I think an efficient warning would be triggered during optree
    optimization, checking whether an op_print or op_printf
    has for parent a non-logical binary op. Thus ignoring completely
    parentheses placement and whitespace amount.

    Thus we would have :

    print (1+1) or die # doesn't warn
    print(1+1) + 1 # warns
    print("some string") > $filehandle # warns ;-)

    Regarding the sort() warning, I suggest to dump it, purely
    and simply.
  • Yitzchak Scott-Thoennes at Sep 11, 2003 at 4:20 pm

    On Thu, Sep 11, 2003 at 03:28:12PM +0200, Rafael Garcia-Suarez wrote:
    Time to give my humble opinion on this long thread :

    the current "print (...)" warning is poorly implemented, and
    the comments in toke.c agree with me. I think it should be
    removed.

    I think an efficient warning would be triggered during optree
    optimization, checking whether an op_print or op_printf
    has for parent a non-logical binary op. Thus ignoring completely
    parentheses placement and whitespace amount.

    Thus we would have :

    print (1+1) or die # doesn't warn
    print(1+1) + 1 # warns
    I think that'll get constant folded before your warning can trigger.
    The precedence warnings we currently have suffer from the same problem:

    $ ./miniperl -we'print 1 == @ARGV ^ 3'
    Possible precedence problem on bitwise ^ operator at -e line 1.
    3
    $ ./miniperl -Ilib -we'use constant args=>0+@ARGV; print 1 == args ^ 3'
    3
  • Yitzchak Scott-Thoennes at Sep 11, 2003 at 4:29 pm

    On Thu, Sep 11, 2003 at 09:19:53AM -0700, Yitzchak Scott-Thoennes wrote:
    On Thu, Sep 11, 2003 at 03:28:12PM +0200, Rafael Garcia-Suarez wrote:
    Time to give my humble opinion on this long thread :

    the current "print (...)" warning is poorly implemented, and
    the comments in toke.c agree with me. I think it should be
    removed.

    I think an efficient warning would be triggered during optree
    optimization, checking whether an op_print or op_printf
    has for parent a non-logical binary op. Thus ignoring completely
    parentheses placement and whitespace amount.

    Thus we would have :

    print (1+1) or die # doesn't warn
    print(1+1) + 1 # warns
    I think that'll get constant folded before your warning can trigger.
    Never mind. You can still catch it just before the + is constant-folded.
    Though I don't think that's the best example. The more common case
    just looks like this:

    print ($a+$b), $c

    Should it only warn when propagating void context into a list whose first
    child (after pushmark) is a print?
  • Rafael Garcia-Suarez at Sep 12, 2003 at 6:36 am

    Yitzchak Scott-Thoennes wrote:
    print(1+1) + 1 # warns
    I think that'll get constant folded before your warning can trigger.
    Never mind. You can still catch it just before the + is constant-folded.
    I don't see any constant folding : print(2)+1 should still warn.
    Though I don't think that's the best example. The more common case
    just looks like this:

    print ($a+$b), $c

    Should it only warn when propagating void context into a list whose first
    child (after pushmark) is a print?
    I vote against :-p
    My proposal is still to make print() warn when its return value is
    used as an operand of a non-logical binary operator. (although I
    don't see yet how to do this efficiently)
  • Michael G Schwern at Sep 11, 2003 at 9:03 pm

    On Thu, Sep 11, 2003 at 03:28:12PM +0200, Rafael Garcia-Suarez wrote:
    Time to give my humble opinion on this long thread :

    the current "print (...)" warning is poorly implemented, and
    the comments in toke.c agree with me. I think it should be
    removed.

    I think an efficient warning would be triggered during optree
    optimization, checking whether an op_print or op_printf
    has for parent a non-logical binary op. Thus ignoring completely
    parentheses placement and whitespace amount.

    Thus we would have :

    print (1+1) or die # doesn't warn
    print(1+1) + 1 # warns
    print("some string") > $filehandle # warns ;-)
    Agreed.

    Regarding the sort() warning, I suggest to dump it, purely
    and simply.
    I've never found the sort warning useful nor heard of anyone finding it
    useful. In fact, I'd forgotten it was there at all. So I have no objections
    to that.


    --
    Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/
    Playstation? Of course Perl runs on Playstation.
    -- Jarkko Hietaniemi
  • Abigail at Sep 11, 2003 at 1:35 pm

    On Thu, Sep 11, 2003 at 09:21:28AM -0400, Kurt Starsinic wrote:
    On Sep 11, Michael Schwern wrote:
    On Thu, Sep 11, 2003 at 10:48:49AM +0200, H.Merijn Brand wrote:
    Though I'm in Abigails camp here (the warning was issued many times, but it
    was *never* wrong), I still can live with that I have to use a plus, or a "",
    in front of the first paren, which opens a new problem: If someone else is to
    maintain my source later, and sees 'print "", (1 + 2) * 3;' it is not unlikely
    that he/she will remove that stupid looking empty string in front, and
    therewith releasing the bogus error^Wwarning.
    Well then don't use "" hackery, use +(...).
    Or ((...)...)

    That's what I always do. I don't think there are too many programmers
    who would be confused by that.

    Nope. That's the entire point of the argument. It will *NOT* make
    the warning go away:

    $ perl -wle 'print ((3 + 4) * 5)'
    print (...) interpreted as function at -e line 1.
    35
    $


    Abigail
  • Chip Salzenberg at Sep 5, 2003 at 6:41 am

    According to Yitzchak Scott-Thoennes:
    On Thu, Sep 04, 2003 at 03:50:12PM +0200, Abigail wrote:
    Since only one person objected, I've made a patch against blead_perl
    that removes this warning.
    ++$objections
    $objections += 2 # my evil twin Skippy doesn't like it either

    --
    Chip Salzenberg - a.k.a. - <chip@pobox.com>
    "I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early." // MST3K
  • Hv at Sep 21, 2003 at 8:42 am
    Abigail wrote:
    :On Mon, Sep 01, 2003 at 02:57:29PM +0200, Abigail wrote:
    :> This is a plea to remove the 'print (...) interpreted as function'
    :> warning.
    :
    :
    :Since only one person objected, I've made a patch against blead_perl
    :that removes this warning.
    :
    :The patch works well with 5.8.1-to-be too.

    Thanks for this, and for everyone's contributions to the discussion
    that preceded and followed it.

    I agree that the current implementation of the warning leads to some
    undesirable results. However the intent of the warning is good and
    valuable. I'd be happy to consider a patch that reduced the false
    positives, but not at the cost of increasing false negatives.

    As Rafael mentions, a better place to check whether the warning is
    needed would be in the optree walk, it is just a question of
    working out which optree shapes should be picked up. That may start
    to get tricky when you consider how to distinguish these two:
    $_ && print (substr $_, -1), "\n" for @vals;
    $_ && print (substr $_, -1), last for @vals;

    Hugo
  • Orton, Yves at Sep 5, 2003 at 2:37 pm

    Even simpler (and more likely from beginners):

    perl -we 'print (3)'
    The quest here was where print *needed* the paren's in order
    to function as expected, but still got the (here wrong) warning.
    Your example could easily do without the parens, but still falls
    in the category warning on perfectly valid code.
    And the way to fix it is to remove the parens.

    D:\Development>perl -we "print (1)"
    print (...) interpreted as function at -e line 1.
    1
    D:\Development>perl -we "print 1"
    1

    Which means that the rule that gets pounded into everybodys head about
    parens being optional when the sub is predeclared gets partially broken.

    So that means this warning could be added to the list of when is calling a
    sub with parens not the same as calling it without.

    Which to me is a really good reason to lose the warning.

    Yves
  • Horsley Tom at Sep 11, 2003 at 12:00 pm

    Yeah, I really enjoy explaining the '+' to new Perl students, and
    various Perl forums. Having to channel obscure magic to avoid Perl
    issuing warnings on common, legitimate code, doesn't do much for the
    image of Perl being a write-only voodoo language.
    What does "image" mean there? Perl *is* a write-only language. I happen
    to love it, but I have no illusions about its write-only nature. As the
    void context map discussion was just pointing out, there are somewhere
    around 13,647,931 different ways to do *everything* in perl. There are
    no two perl programmers who write in the same subset of all those choices.
    That's a write-only language if I ever saw one :-).

Related Discussions

People

Translate

site design / logo © 2022 Grokbase