in reply to Re^3: Unhappy returns
in thread Unhappy returns

The difference is that foreach is a statement, and as such does not return anything. The context in which its body is evaluated is therefore never of any interest, any more than it is of interest which context the body of an if or while is evaluated in.

map and grep OTOH are expressions and do return something; which means context is paramount.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re^5: Unhappy returns
by ysth (Canon) on Oct 10, 2005 at 15:23 UTC
    I'd have to disagree. Every runtime statement in perl does have a return value. It's not true that foreach doesn't return anything. Ponder this piece of code: 
    @x = sub { 0; for (4,3,2) { 1 } }->();

    [download]
    What does the sub return? Is it a bug? What should it return? (It has to return something, even if it's an empty list.) Also compare to 
    @x = sub { }->();

    [download]
    and 
    $x = sub { 0; for (4,3,2) { 1 } }->();

    [download]
[reply]
[d/l]
[select]

      What does the sub return?

      The foreach in your examples is a red herring. A function call is an expression. And function calls return the value of the last expression evaluated. foreach is not an expression, but in the course of its execution several of those may be evaluated.

      My statement stands. (Pun intended.)

      Makeshifts last the longest.

[reply]
        Then where does the return value come from? What expression is it?
        And function calls return the value of the last expression evaluated.
        I think it is possible to have a mostly consistent understanding based on that "rule", but it involves thinking of void-context expressions as having values. IMO it is a lot simpler (and completely instead of mostly consistent) to think of every statement as having a context and a return value. This issue with for loops is one place where the two models show their difference.
[reply]
      It's not true that foreach doesn't return anything.

      Sure it is. Otherwise, you would not have had to wrap your example for loops in a sub to try to make your point. If it returned something, you'd be able to write code like: @x = for (1) { 1 }; But, that's a syntax error. Why? Because statements don't return anything. Q.E.D.

      -sauoq
"My two cents aren't worth a dime.";
[reply]
[d/l]
[select]
        Sure it is. Otherwise, you would not have had to wrap your example for loops in a sub to try to make your point.
        I wrapped it in a sub because that's one way to put a for loop in a non-void context. Note that the very fact that I am speaking of the "context" of a statement demonstrates that statements can be said to have return values. But also see the reply I'm about to make to Re^5: Unhappy returns.
        @x = for (1) { 1 }; But, that's a syntax error. Why? Because statements don't return anything.
        No, it's a syntax error because the whole thing is a statement that is an expression (one of the possible kinds of statement), and the expression is a list assignment which has the form expression = expression. So all you've proved is that for (1) { 1 } isn't an expression. IMO by your argument, @x = do { for (1) { 1 } }; should be a syntax error, too, and it isn't.
[reply]
[d/l]
[select]

In Section Meditations