Re: expressions vs. statements

[Paul Prescod <address@hidden>]

Guy Steele - Sun Microsystems Labs wrote:
> 
>...
> 
>                                                     If you want it to be
>    the value of the block you should say so. ...
> 
> (a) Why?

Because it could be that it just happened to be the last line in the
block. It's ambiguous whether it just ended up at the end or was
deliberately put there to trigger a return value.

> (b) One could argue that you *do* say so: the way that you
>     say what the value of a block is, is to state that value at
>     the end of the block.

I just prefer to separate the two issues to avoid an "accidental" return
value.

> (c) What, did you want a "noise word"?  A noise word makes sense
>     if returning a special value is the uncommon case.  Maybe in
>     your style of programming or your favorite language, that is
>     indeed an uncommon case.  But what if it were the common case
>     (as it is in Lisp)?

Yes, I agree that in a functional language, an explicit return keyword
is less important. But in a procedural/OO language, I think it is
clearer to differentiate between the last instruction in a block and the
return value. That's why I like the statement/expression distinction in
procedural or OO languages.

Note that the original context of this question was Python, but even in
Scheme. R5RS says "the value of for-each is undefined" I see that as
another way of saying: "this is a statement, not an expression." If
Scheme were my language, I might explicitly disallow the binding of that
return value to a name.

> (d) would you be happier if there were no semicolon after the 5?

No.

I don't feel strongly about this issue but I think that in a
procedural/OO language it helps to regularize code and discourage a
deeply nested style.


 Paul Prescod