RE: expressions vs. statements

["David Simmons" <address@hidden>]

I hear the expression of major concern or conclusions about the negative
aspects/inherent problems in languages that do not have what are being
termed "statements" that do not evaluate to a "value". 

However, of all the (many) things people have complained or been
concerned about in Smalltalk. I have never (not once) heard this
(everything has a value, there are no "statement" distinctions) as being
a problem in Smalltalk where every operation is effectively a message
and thus every operation has a "value". 

I.e., where the result of a control-flow expressions can assigned or
returned. And where lexical scopes (blocks) are semantically real
objects that when evaluated return (by default) their last expressions
value.

I surmise this has more to do with the age of the language (implying the
difference lies in the incorporated experience and maturity
[consistency] level of its frameworks and the base of established best
practice patterns of usage). An area where Smalltalk vendors and
developers have, historically, spent enormous energy and resources to
enable supporting the processes necessary for managing complex system
projects.

One thing that is dominant in Smalltalk, because developers do not focus
on [are free from] type-declarations and lots of syntax, is a focus on
design itself and best practices. That's why so much pattern and design
work evolved from the Smalltalk space, and its why XP came out of the
Smalltalk space.

-- Dave S. [SmallScript LLC]

SmallScript for the AOS & .NET Platforms
David.Simmons@SmallScript.com | http://www.smallscript.org


> -----Original Message-----
> From: owner-ll1-discuss@ai.mit.edu
[mailto:owner-ll1-discuss@ai.mit.edu]
> On Behalf Of Pixel
> Sent: Wednesday, December 19, 2001 4:44 PM
> To: Kragen Sitaker
> Cc: ll1-discuss@ai.mit.edu
> Subject: Re: expressions vs. statements
> 
> kragen@pobox.com (Kragen Sitaker) writes:
> 
> [...]
> 
> > The consequence is that your function returns some value, even if
you
> > didn't really intend for it to do so.  This means that whenever you
> > change the function, you need to either maintain the same return
value
> > (possibly leading to wordier code, inefficiency, or in the worst
case,
> > the inability to make code correct) or verify that nobody is using
the
> > return value.
> 
> I confirm this is a problem in Perl. I have some functions that ends
with:
> --------------------
>    if () {
>       ...
>    } else {
>       ...
>    }
> }
> --------------------
> where the if_then_else returns an error/warning value.
> 
> When you want to add some code after it, you must check wether the
return
> value was wanted and used by some caller. Adding debugging statement
after
> the
> if_then_else may cause havoc!
> 
> [...]
> 
> > I don't think this issue is terribly important in language design,
but
> > it's obvious to me that the right answer is that most blocks of
> > sequential statements shouldn't return a meaningful value.
> 
> agreed for while/for. My only problem is with if_then_else which
return
> value
> is useful. Alas in perl you can't write "return if () ..." to
disambiguate.