Re: expressions vs. statements

[Scott McKay <address@hidden>]

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
>value.

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
language.

>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.

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
"too deeply".