Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!mcsun!corton!irisa!jezequel
From: jezequel@irisa.fr (Jean-Marc Jezequel)
Newsgroups: comp.lang.eiffel
Subject: Re: Functions without side effects (was Old confusion)
Message-ID: <1991Jun5.072556.19870@irisa.fr>
Date: 5 Jun 91 07:25:56 GMT
References: <130242@tut.cis.ohio-state.edu>
Sender: news@irisa.fr
Organization: IRISA, Rennes (FR)
Lines: 46

From article <130242@tut.cis.ohio-state.edu>, by ogden@seal.cis.ohio-state.edu (William F Ogden):
> In article <1991Jun3.145924.28406@mstr.hgc.edu> jcm@mstr.hgc.edu (James McKim) writes:
>    ...
>>Let me try to summarize the discussion so far. The question before
>>the groups is "Should there exist a dichotomy between functions and procedures
>>within a class? In particular, should functions return information
>>about the state of an object _without_ changing that state (at least
>>as far as a user of the object can tell) while procedures are used
>>to change the state of the object _without_ returning a value.
>>
>>So far the two most extreme views are held by Craig Chambers and myself.
>>
>>Craig feels that procedures that return values are often extremely
>>useful and so should be designed into the class as a matter of course.
>>He cites Pop and Top in a stack class as a prime example. Top returns
>>the obvious item from the stack with no side effects. Pop removes the
>>top item _and_ returns it. His argument being, I believe, that the
>>vast majority of the time the user will want to use the item she just
>>popped. (Is that a fair summary Craig?)
>>
>>I feel that the separation of concerns that the proposed dichotomization
>>between functions and procedures is too important to give up lightly.
>>The designer of a class should expect to design procedures that don't
>>return values and functions without side effects, and only vary from
>>this heuristic when there is a _compelling_ reason to do so. Thus my
>>Pop would just remove the top element, not return it.

Let me summarize even further: It seems that we all agree on:
1) Functions with side effects are dangerous, and don't follow the
road towards better software quality
2) Procedures which return values are often usefull

So why not trying to make a syntatical difference between the two
concepts (keyword like "pure" for pure functions)?
I guess it is too late for Eiffel V3, but may be for V4, when we (hope
to) have tools to make static analysis of programs in order to prove
correctness of pieces of code (i.e. ensuring postconditions and
invariants from preconditions and code), and so on.

+----------------------------------------------------------------------------+
| Jean-Marc Jezequel, IRISA/CNRS, 35042 RENNES (FRANCE) // jezequel@irisa.fr |
+----------------------------------------------------------------------------+
-- 
+----------------------------------------------------------------------------+
| Jean-Marc Jezequel, IRISA/CNRS, 35042 RENNES (FRANCE) // jezequel@irisa.fr |
+----------------------------------------------------------------------------+