Re: expressions vs. statements

[Guy Steele - Sun Microsystems Labs <address@hidden>]

   Date: Wed, 19 Dec 2001 12:36:32 -0500
   From: Paul Prescod <paul@prescod.net>
   X-Accept-Language: en
   To: ll1-discuss@ai.mit.edu
   Subject: Re: expressions vs. statements
   
   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.

Then we are in agreement.  But I wanted to
see your reasoning articulated.  Thanks.

--Guy