Newsgroups: comp.lang.eiffel
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!mstr!mstr!jcm
From: jcm@mstr.hgc.edu (James McKim)
Subject: Re: Functions without side effects (was Old confusion)
Message-ID: <1991Jun7.135613.1515@mstr.hgc.edu>
Sender: Usenet@mstr.hgc.edu (Action News Central)
Nntp-Posting-Host: sc3.hgc.edu
Reply-To: jcm@mstr.hgc.edu (James McKim)
Organization: The Hartford Graduate Center, Hartford CT.
References: <1991May30.141218.3446@mstr.hgc.edu> <130803@tut.cis.ohio-state.edu>
Date: Fri, 7 Jun 91 13:56:13 GMT

In article <130803@tut.cis.ohio-state.edu> ogden@seal.cis.ohio-state.edu (William F Ogden) writes:
>In article <1991Jun5.144629.5030@mstr.hgc.edu> jcm@mstr.hgc.edu (James McKim) writes:
>
>  [my post about functions vs procedures and the Pop/Top choice deleted]
>
>>Now I'm confused. The first part of your post argues that functions
>>should, in general, not have side effects that change the visible state
>>of an object. The second part argues that procedures, which do change
>>the state, should often have return values. Are you making a distinction
>>between functions with side effects and procedures with return values?
>
>Indeed. This distinction is based on the fact that functions can be composed
>into arbitrarily structured expressions in which the order of evaluation
>is uncertain, whereas procedure calls can only be composed in simple
>sequences in which the order of execution is obvious.
>
Well, maybe I'm being dense, but I don't think you've made any real
distinction between functions with side effects and procedures with
return values. What you've said is that functions without side effects
"can be composed into arbitrarily structured expressions in which the 
order of evaluation is uncertain" (I agree BTW), and that functions with
side effects cannot.

>>I also must question the premise of the second part of your argument.
>>Most of the OO data structure classes I have seen use referential
>>semantics, so a function like Top does not necessarily involve any
>>replication beyond that of a pointer. 
>
>Referential semantics do address the efficiency of replication problem,
>but unfortunately, in most situations they undermine comprehensibility.
>In this case, if a client uses the Top operation to obtain a `copy' of
>some large object from a stack, does a few operations on this copy while
>pushing a few more objects on the stack, then she will be quite surprised
>to discover that the value of the entry in the stack from which the
>copy was made has changed in value. Now the Top operation itself might
>be a `side effect free' function in such an implementation, but the
>resulting system would fraught with strange side effects.
>
Absolutely right. (But you didn't need me to tell you that :-)) The
specs of the class must make clear whether the client is receiving
a reference or a copy. When referential semantics are used the client
has extra concerns. This is a classic efficiency/simplicity tradeoff.

>>                                      But even if I agree that such
>>replication _should_ be the norm I would argue for Top as a side
>>effect free function and Pop as a return free (to coin a phrase)
>>procedure on the basis of comprehensibility. If a particular application
>>requires the efficiency of a Pop_Top then extend the class, possibly
>>via inheritance to include it, but don't include it as a matter of
>>course. All such features make the class harder to understand, and
>>if done as a matter of course there will be _lots_ of them. All the
>>efficiency in the world won't help if users, maintainers, implementers
>>cannot understand the class.
>
>Actually, `Pop_Top' is quite comprehensible and at least as useful as
>the Top and Pitch_Top operations. 
>
>Certainly many classes are now being designed to include far too many 
>primary operations, as you observe.

Right, it's not Pop_Top itself that I'm concerned with, it's the
mode of thinking that makes Pop_Top the default.

> However, if you analyze the
>situation here, you will find that it's the traditional Top and Pitch_Top
>operations which are really secondary and thus should be added as
>extensions to the basic stack class.
>
Whoa! I thought you were at least willing to include _Top_ as a primary
feature. If you only have Pop_Top then every time you need to make a
decision based on the current top, you have to pop the item, save it
since it's no longer on top of the stack, do whatever else you
want to do with it being careful not to change it, and then
push it back on the stack.

In any case, my analysis differs from yours, I still want Top and Pop
(Pitch_Top) as the primary features.
>
>--
>
>/Bill

-- Jim




*------------------------------------------------------------------------------*
Jim McKim  (203)-548-2458   _Give_ people fish and they eat for a day.  
Internet:  jcm@mstr.hgc.edu _Teach_ people to fish and they eat for a lifetime.
