[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: expressions vs. statements
At 12:36 PM 12/19/01, Paul Prescod wrote:
>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.
And the consequence is...?
Should it be an error to call a value-returning function in a language
like Java, without assigning the value to a variable?
> > (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
Since any type-safe language will catch the "accidents" at compile time,
I don't see why you are concerned. Oh, note the plural:
- In a language with only expressions, the accident is when you return
a value of the wrong type.
- In a language with statements, the accident is forgetting the 'return'.
> > (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.
Nobody complained about this in Dylan, which *looks* like a statement-y
>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?
>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.
Most Lispers and Schemers I know introduce local variables when the
indentation gets deep enough that the code doesn't fit in a 80-column
(or so) line. Typographic readability encourages you not to nest