Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!tut.cis.ohio-state.edu!seal.cis.ohio-state.edu!ogden
From: ogden@seal.cis.ohio-state.edu (William F Ogden)
Newsgroups: comp.lang.eiffel
Subject: Re: Functions without side effects (was Old confusion)
Message-ID: <130803@tut.cis.ohio-state.edu>
Date: 5 Jun 91 23:34:38 GMT
References: <1991May30.141218.3446@mstr.hgc.edu> <130242@tut.cis.ohio-state.edu> <1991Jun5.144629.5030@mstr.hgc.edu>
Sender: news@tut.cis.ohio-state.edu
Organization: The Ohio State University, Department of Computer and Information Science
Lines: 54

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.

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

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


--

/Bill