Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!sunic!news.funet.fi!tukki.jyu.fi!sakkinen
From: sakkinen@jyu.fi (Markku Sakkinen)
Newsgroups: comp.lang.eiffel
Subject: Re: Old confusion
Keywords: result, side effects
Message-ID: <1991May27.070430.26384@jyu.fi>
Date: 27 May 91 07:04:30 GMT
References: <1991May21.040742.1520@syacus.acus.oz.au> <1166@tetrauk.UUCP> <1991May23.212347.23486@leland.Stanford.EDU>
Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen)
Distribution: comp
Organization: University of Jyvaskyla, Finland
Lines: 56

In article <1991May23.212347.23486@leland.Stanford.EDU> craig@self.stanford.edu (Craig Chambers) writes:
>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
>|>  [...]
>
>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
>  [...]
>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?

No real answer, but ...
For comparison, the 'const' specifier for C++ "member functions"
(introduced in Version 2.0 or 2.1) refers to the concrete state.
Peter Grogono's language Dee (article in Structured Programming,
January 1991) follows actually the same principle;  but 'function'
means something that does not alter the 'self' object nor any of its
components, and 'procedure' may both alter them and return a result.
(This is what Craig suggested for Eiffel, too.)

Somehow the alternative chosen for Eiffel looks well in line with
other design decisions in the language, but in principle
one could have _both_ degrees of side-effect freedom available.
To go a bit further, a _true_ function should not be allowed to
have side effects anywhere (except possibly benign ones), including
parameters and global variables.  Such constraints don't exist in C++,
nor in Dee as far as I know.

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

I like the compromise solution.
Of course, "functions" are only syntactic sugar for a special case
(exactly one result to return) if procedures can have 'out' parameters.
Here the problem with Eiffel, and other languages that have adopted
Lisp-like reference/value semantics, is that you cannot use a parameter
of an _atomic_ type to return a result.  I suppose that holds also
for expanded types in current Eiffel; am I wrong?

Markku Sakkinen
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
          SAKKINEN@FINJYU.bitnet (alternative network address)