printing the result of a procedure call

Discussion in 'Perl Misc' started by Helmut Richter, Sep 26, 2010.

  1. What is the difference of

    - calling a procedure to get a result, and *then* printing the result

    and

    - calling a procedure as a parameter of print?

    Example:

    ----> cat ./tt
    #! /usr/bin/perl

    print "\nfirst try:\n";
    $z = proc (1);
    print $z;

    print "\nsecond try:\n";
    print (proc (1));

    sub proc {
    return "result\n";
    };

    ----> ./tt

    first try:
    result

    second try:

    ---->

    I expected twice the same result.

    --
    Helmut Richter
     
    Helmut Richter, Sep 26, 2010
    #1
    1. Advertising

  2. Helmut Richter <> wrote:
    >What is the difference of
    > - calling a procedure to get a result, and *then* printing the result
    >and
    > - calling a procedure as a parameter of print?


    None.

    >Example:
    >
    >----> cat ./tt
    >#! /usr/bin/perl
    >
    >print "\nfirst try:\n";
    >$z = proc (1);
    >print $z;
    >
    >print "\nsecond try:\n";
    >print (proc (1));
    >
    >sub proc {
    > return "result\n";
    >};
    >
    >----> ./tt
    >
    >first try:
    >result
    >
    >second try:
    >
    >---->
    >
    >I expected twice the same result.


    But in the second case you didn't call proc().

    Why aren't you using strict and warnings? If you had used strict and
    warnings then perl would have told you what's wrong.

    Solutions:
    a: predeclare sub proc;
    b: use
    print (proc(1));
    instead of
    print (proc (1));

    jue
     
    Jürgen Exner, Sep 26, 2010
    #2
    1. Advertising

  3. On Sun, 26 Sep 2010, wrote:

    > But in the second case you didn't call proc().
    >
    > Why aren't you using strict and warnings? If you had used strict and
    > warnings then perl would have told you what's wrong.


    That's correct -- I should have done that.

    > Solutions:
    > a: predeclare sub proc;
    > b: use
    > print (proc(1));
    > instead of
    > print (proc (1));


    c: use &proc. This is how I did it for more than a decade, and it works
    with a blank after the procedure name as well as without. Now, for
    whatever reason, I find it nicer without the &, and I simply did not
    expect that it would have so much of an effect in the tiny fraction of
    cases where it matters -- probably *only* with print and similar commands.

    (In the meantime, it has become fashionable not to write parentheses at
    all, but it might take me another decade to get used to it enough to be
    able to see where the parameter list ends.)

    Thanks to all who responded!

    --
    Helmut Richter
     
    Helmut Richter, Sep 27, 2010
    #3
  4. On 27.09.2010 09:30, Helmut Richter wrote:
    > c: use &proc. This is how I did it for more than a decade, and it works
    > with a blank after the procedure name as well as without. Now, for
    > whatever reason, I find it nicer without the &, and I simply did not
    > expect that it would have so much of an effect in the tiny fraction of
    > cases where it matters -- probably *only* with print and similar commands.
    >
    > (In the meantime, it has become fashionable not to write parentheses at
    > all, but it might take me another decade to get used to it enough to be
    > able to see where the parameter list ends.)


    It is very bad style to use &proc - unless you know what you're doing.
    For one thing, the & overrides prototypes. As a second thing, as you
    mention leaving out parentheses: note that proc(); and &proc; do
    different things. The first form passes an empty argument list, the
    second form passes @_! (or maybe better: the first form clears @_ for
    the sub proc while &proc does not change @_).

    Don't use &proc if you can use proc() instead.

    Wolf
     
    Wolf Behrenhoff, Sep 27, 2010
    #4
  5. Helmut Richter <> wrote:
    >On Sun, 26 Sep 2010, wrote:
    >
    >> But in the second case you didn't call proc().
    >>
    >> Why aren't you using strict and warnings? If you had used strict and
    >> warnings then perl would have told you what's wrong.

    >
    >That's correct -- I should have done that.
    >
    >> Solutions:
    >> a: predeclare sub proc;
    >> b: use
    >> print (proc(1));
    >> instead of
    >> print (proc (1));

    >
    >c: use &proc.


    Hmmmm, no. That would have a quite different semantic.
    And if you don't know what that different semantic is then you don't
    want to use &proc.
    It is a very rare case that &proc is actually useful.

    jue
     
    Jürgen Exner, Sep 27, 2010
    #5
  6. On Mon, 27 Sep 2010, Wolf Behrenhoff wrote:

    > On 27.09.2010 09:30, Helmut Richter wrote:
    > > c: use &proc. This is how I did it for more than a decade, and it works
    > > with a blank after the procedure name as well as without. Now, for
    > > whatever reason, I find it nicer without the &, and I simply did not
    > > expect that it would have so much of an effect in the tiny fraction of
    > > cases where it matters -- probably *only* with print and similar commands.
    > >
    > > (In the meantime, it has become fashionable not to write parentheses at
    > > all, but it might take me another decade to get used to it enough to be
    > > able to see where the parameter list ends.)

    >
    > It is very bad style to use &proc - unless you know what you're doing.
    > For one thing, the & overrides prototypes. As a second thing, as you
    > mention leaving out parentheses: note that proc(); and &proc; do
    > different things. The first form passes an empty argument list, the
    > second form passes @_! (or maybe better: the first form clears @_ for
    > the sub proc while &proc does not change @_).
    >
    > Don't use &proc if you can use proc() instead.


    I will in the future. But when I learnt perl, &proc was the standard way
    of writing procedure calls -- see the camel book, edition March 1992.
    Well, the oldest of my scripts I still use on a regular basis is from 2001
    -- I have no idea what was then the preferred way of writing procedure
    calls. (That's how you discover you're getting real old.) By and large,
    language changes have been upward compatible over time, though.

    My problem was not language change but ambiguity: what I had written
    allowed two different ways of syntactic decomposition, of which I only saw
    one. Even if I had seen both, I would not have been able to tell which of
    them the compiler/interpreter would assume to be the correct one, and I
    see no way to determine that from any language description I have. So "use
    warnings" is indeed the right (the only?) way to resolve the ambiguity.

    --
    Helmut Richter
     
    Helmut Richter, Sep 27, 2010
    #6
  7. Helmut Richter

    Uri Guttman Guest

    >>>>> "HR" == Helmut Richter <> writes:

    >> Don't use &proc if you can use proc() instead.


    HR> I will in the future. But when I learnt perl, &proc was the
    HR> standard way of writing procedure calls -- see the camel book,
    HR> edition March 1992. Well, the oldest of my scripts I still use on
    HR> a regular basis is from 2001

    and perl5 has been out since 1993 with 5.004 (first decent version) out
    in 1997. perl4 required the &foo call style and perl5 didn't. so you
    have been way out of touch thinking & was needed or normal.

    HR> -- I have no idea what was then the preferred way of writing
    HR> procedure calls. (That's how you discover you're getting real
    HR> old.) By and large, language changes have been upward compatible
    HR> over time, though.

    perl4 was very compatible with perl5 but that doesn't mean newer ways
    didn't obsolete older one. real references made using typeglobs and/or
    symbolic references obsolete. calling subs with foo() made &foo
    obsolete.

    HR> My problem was not language change but ambiguity: what I had
    HR> written allowed two different ways of syntactic decomposition, of
    HR> which I only saw one. Even if I had seen both, I would not have
    HR> been able to tell which of them the compiler/interpreter would
    HR> assume to be the correct one, and I see no way to determine that
    HR> from any language description I have. So "use warnings" is indeed
    HR> the right (the only?) way to resolve the ambiguity.

    where have you been for 13 years? you never saw foo() in any perl code
    since then? on cpan? cow-orkers? web scripts? it make little sense to
    keep programming in a language for 15+ years and not knowing about any
    changes in it.

    uri

    --
    Uri Guttman ------ -------- http://www.sysarch.com --
    ----- Perl Code Review , Architecture, Development, Training, Support ------
    --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
     
    Uri Guttman, Sep 27, 2010
    #7
    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. ALuPin
    Replies:
    3
    Views:
    839
    Mike Treseler
    Jan 5, 2005
  2. Lacka
    Replies:
    2
    Views:
    860
    Lacka
    Dec 31, 2004
  3. Mike P
    Replies:
    0
    Views:
    3,307
    Mike P
    Jun 19, 2006
  4. AlexWare
    Replies:
    2
    Views:
    761
    Paul Uiterlinden
    Oct 23, 2009
  5. Michael Tan
    Replies:
    32
    Views:
    991
    Ara.T.Howard
    Jul 21, 2005
Loading...

Share This Page