Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!uupsi!mstr!mstr!jcm
From: jcm@mstr.hgc.edu (James McKim)
Newsgroups: comp.lang.eiffel
Subject: Re: Functions without side effects (was Old confusion)
Message-ID: <1991Jun10.151959.29568@mstr.hgc.edu>
Date: 10 Jun 91 15:19:59 GMT
References: <1991May30.141218.3446@mstr.hgc.edu> <131732@tut.cis.ohio-state.edu>
Sender: Usenet@mstr.hgc.edu (Action News Central)
Reply-To: jcm@mstr.hgc.edu (James McKim)
Organization: The Hartford Graduate Center, Hartford CT.
Lines: 79
Nntp-Posting-Host: sc3.hgc.edu

In article <131732@tut.cis.ohio-state.edu> ogden@seal.cis.ohio-state.edu (William F Ogden) writes:
>In article <1991Jun7.135613.1515@mstr.hgc.edu> jcm@mstr.hgc.edu (James McKim) writes:
>
>   [Quote deleted]
>
>>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.
>
>OK. Let's look at the side effecting function Pop_of vs. the value
>returning Pop_Top procedure on stacks of say integers. If we have
>a stack whose top two entries are say 5 and 3, then, because there's
>an indeterminate order of evaluation problem even in fairly simple 
>situations, executing
>
>  Dif := Pop_of(S) - Pop_of(S);
>
>might cause Dif to be either 2 or -2. In contrast, with the Pop_Top
>procedure, there can be no uncertainty because a programmer must
>explicitly sequence the operations.
>  Pop_Top(S,t1);
>  Pop_Top(S,t2);
>  Dif := t1 - t2;   {or t2 - t1}
>

OK, so when you say 'procedure with a return value' you mean the
value is returned through arguments of the procedure. Conceptually,
this is still a function with side effects (the return value is just
in a different place). The distinction depends on the language
definition or implementation.

>
>>> However, if you analyze the
>>>situation here, you will find that it's the traditional Top and Pitch_Top
>>>operations which are really secondary  ...
>
>>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.
>
>Fine. Let's analyze your alternative:
>  ...then every time you need to make a decision based on the current top,
>you have to [pop the item] apply the Top function, save [it since it's no
>longer on top of the stack] the resulting item reference, do whatever else
>you want to do with it being careful not to change it, and then [push it
>back on the stack] destroy the reference so you won't inadvertently modify
>the referenced item. That's a wash in my book, but Top bought us a bunch
>of aliasing problems that Pop_Top avoided.
>
Touche! However, I still favor Top as the conceptually simpler operation. If
we extend your reasoning, any time I merely want to glance at an element
of any data structure, I have to remove it and then restore it. Better
to keep the simpler operations and look for more efficient ways to 
implement them.
>
>At a visceral level, I suppose that all us old timers want Top and Pop
>to turn out to be the right design, because that's what we grew up
>with. However, analytically, ...
>
Well, I must be an older timer than you :-) All my old data structures
books have pop_top.
>
>--
>
>/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.