Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

Re: Re: Re: Re: Want a Hashref. Getting a List in Scalar Context.

by chip (Curate)
on May 04, 2004 at 20:52 UTC ( #350559=note: print w/replies, xml ) Need Help??

in reply to Re: Re: Re: Want a Hashref. Getting a List in Scalar Context.
in thread Want a Hashref. Getting a List in Scalar Context.

Additional redundancy may improve readability for newbies, but that way lay the elimination of all implicit features, and then you've got Python.

"Final expression is return value" is an easy and basic meme for Perl, going all the way back to Perl 1. The unnecessary use of return deserves, not recommendation, but quiet disdain.

    -- Chip Salzenberg, Free-Floating Agent of Chaos

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Want a Hashref. Getting a List in Scalar Context.
by itub (Priest) on May 04, 2004 at 22:11 UTC
    Adding an explicit return is just like adding "unneeded" parentheses: a way of expressing things more explicitly (and maybe more clearly) if the author wants. Let people write with their own style; I see no need for disdain or for fear that explicit returns will be mandatory in the future. I agree that freedom should remain one of the attractive features of Perl; people who want to have only one way of doing things have other languages to choose from.
Re: Re: Re: Re: Re: Want a Hashref. Getting a List in Scalar Context.
by diotalevi (Canon) on May 04, 2004 at 21:17 UTC
    I dunno, I'm not a newbie and I like seeing it. Its strange to write return() in some places but not others. I suppose I could think of it like writing scalar() some places but I haven't.
      When you think of "return" as "return from this subroutine early", it becomes very clear where you need it: everywhere that you want the subroutine to abort before it would have otherwise. And, by the way, you can also specify the "last expression evaluated" as a convenience after the return. {grin}

      -- Randal L. Schwartz, Perl hacker
      Be sure to read my standard disclaimer if this is a reply.

Re^5: Want a Hashref. Getting a List in Scalar Context.
by hv (Parson) on May 04, 2004 at 23:40 UTC

    I think your disdain may be misplaced. Whenever writing perl code it is always important to consider the audience for the code you are writing; the compiler is one member (and a very important member) of that audience, but so are you as the author, and often so are other people that may need to maintain it or desire to understand it in the future.

    I frequently use return at the end of a function or method. I frequently omit return at the end of a function or method. Which I choose to do in any particular situation is primarily down to whether I feel the return adds clarity.

    It is rare that I write code that is so resource-critical an extra opcode would make a difference; when I do, of course, I don't use return.


Re: Re: Re: Re: Re: Want a Hashref. Getting a List in Scalar Context.
by ambrus (Abbot) on May 05, 2004 at 12:57 UTC

    Actually, this "Final expression is return value" is IMO a mistake of perl. The final expression should only mean a return value iff it's not followed by a semicolon.

    That can only be done in free-form languages (where a newline doesn't mean end of the command, like perl or C but unlike awk or ruby or python). That way, you wouldn't have to add return (or undef) statements just to make a function void.

    Yes, there's already one such language: Mathematica treats semicolon as an operator that just returns its second argument (like scalar comma in perl, comma operator in C, begin in scheme). It's a function like any operator in Mathematica (well, any but one, @@@), it's called CompoundExpression. When it is used without second argument (that is, when you just put a semicolon after an expression) the second argument is implicitly Null.

    Update: fixed a typo.

      The final expression should only mean a return value iff it's not followed by a semicolon
      That's a joke, right? (I say hopefully...)

      If not, what happens when you use a void-return function in non-void context; a fatal error? silent promotion to undef/empty list? Camels fly out your nose?

      Not to be critical, that's a really lousy idea. If you want to forbid attempts to use a return value, say carp "blah" if defined wantarray;

        No. Let me elaborate.

        My proposal is that when there's a semicolon after the last statement, the subroutine (either anonymous or not) should return undef or empt list depending on the context (unless you exited it with a return statement), else ti would return the result of the last statement.

        This would be better both in the case of a void and a non-void subroutine. If you want to create a void subroutine, you just omit the semicolon after the last statement. This causes no ambignuity, as the commands that usually don't need to end in a semicolon (if, while, for etc) are void anyway. In perl, if you have a subroutine whose last statement is an expression, you now have to add an additional return or () to amke the function void.

        Why would one want to make a function void? If a function returns a value, someone might use it accidentally and don't easily see the error; if the function is void, the undefined return value in scalar context is likely to give an undef warning. Worse still, someone may find that a function that you intended to be void returns a particular kind of information. Later when you change the function, his code just fails to work, as you don't care what the sub returned as it's meant to be void.

        In case of non-void subs, you just had to take care not to add a semicolon; you already often do that when writing short blocks for map etc, don't you?

        This is not entirely inlogical, you can also think of it like this: tha last statement must never end in a semicolon. If there's a semicolon there, then an empty statement is following it, which should be defined to have a result of () (it now doesn't as sub a {2;;;} a returns 2 despite of the apparent empty statements.

        Of course, this is just a speculation, too late to change now, it would yield to a lot of incompatibility. Perl should remain as is.

        Update: I was wrong. As ysth pointed in his reply, the "last expression" rule goes inside if and while (and strangely it seems to return the evaluated condition of a prefix if statement without an else branch, and also with a postfix if,unless,while conditions but not the others). The semicolon rule I've sketched would not fit well with this behaiviour.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://350559]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (7)
As of 2018-06-18 23:50 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (111 votes). Check out past polls.