Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!spool.mu.edu!samsung!uunet!stanford.edu!leland.Stanford.EDU!leland.Stanford.EDU!craig
From: craig@leland.Stanford.EDU (Craig Chambers)
Newsgroups: comp.lang.eiffel
Subject: Re: Old confusion
Keywords: old, ensure, postconditions
Message-ID: <1991May23.212347.23486@leland.Stanford.EDU>
Date: 23 May 91 21:23:47 GMT
References: <1991May21.040742.1520@syacus.acus.oz.au> <1166@tetrauk.UUCP>
Sender: news@leland.Stanford.EDU (Mr News)
Reply-To: craig@self.stanford.edu
Distribution: comp
Organization: Stanford University
Lines: 46

In article <1166@tetrauk.UUCP>, rick@tetrauk.UUCP (Rick Jones) writes:
|> The Eiffel "philosophy" is that routines should be either functions
|> or procedures;  i.e. a routine which returns a value is a function, and should
|> always be written without side effects.  It can therefore be called repeatedly
|> without changing the state of the system.  A procedure which does change the
|> state should not have a return value.
|> 
|> The compiler can never totally enforce this, although it does produce warnings
|> if you call a function and don't assign its return value.

The compiler *could* enforce that functions have no side-effects.
According to OOSC, this restriction is not enforced because it should
be legal to make "benevolent" side-effects to the concrete state as
long as the abstract state is not affected (and it's probably
impossible in general to verify that the abstract state doesn't
change, especially since there's no specification of what the abstract
state is and how it's constructed from the concrete state).

I have two questions of Eiffel converted.

1. How often do functions make benevolent side-effects to the concrete
state that do not affect the abstract state?  If much of the system
relies on functions being side-effect-free (e.g. assertions), then
wouldn't the advantages of compiler-enforced purity of functions
outweigh the advantages of allowing benevolent side-effects?

2. Do you actually believe that functions should be side-effect-free?
My view is that side-effecting procedures (even of the abstract state)
that return a result are too useful to forgo.  For example, when I
call Stack.Pop I want to get back the element popped off the stack; I
don't want to have to call Stack.Top, save the result somewhere, and
then call Stack.Pop to remove it from the stack. Also, I believe that
somewhere in OOSC (I can't find it now) is described a technique
whereby instead of writing a side-effecting function (a procedure that
returns a result) the programmer writes a procedure that stores its
result in some instance variable which can then be accessed by a
corresponding function.  This approach seems silly; it's more verbose
for the programmer (both the class implementor and the client) and
less efficient since I assume an extra word of storage needs to be
allocated in every such object.

Perhaps an intermediate step would be to support both procedures that
can return results *and* compiler-enforced side-effect-free functions;
only the latter could be used in assertions.

-- Craig Chambers