Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cis.ohio-state.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: <131732@tut.cis.ohio-state.edu>
Date: 7 Jun 91 23:15:42 GMT
References: <1991May30.141218.3446@mstr.hgc.edu> <130803@tut.cis.ohio-state.edu> <1991Jun7.135613.1515@mstr.hgc.edu>
Sender: news@tut.cis.ohio-state.edu
Organization: The Ohio State University, Department of Computer and Information Science
Lines: 69

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}

>           ....       When referential semantics are used the client
>has extra concerns. This is a classic efficiency/simplicity tradeoff.

Actually, this particular one is a manufactured efficiency/simplicity
tradeoff created by the designer's insistence upon foisting off the Top
operation on unsuspecting clients.
  ....
>Right, it's not Pop_Top itself that I'm concerned with, it's the
>mode of thinking that makes Pop_Top the default.

So I see.

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

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

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


--

/Bill