Xref: utzoo comp.lang.eiffel:1613 comp.software-eng:5843
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uunet!mcsun!corton!irisa!mbenveni
From: mbenveni@irisa.fr (Marc Benveniste)
Newsgroups: comp.lang.eiffel,comp.lang.object,comp.software-eng
Subject: Re: Functions without side effects (was Old confusion)
Message-ID: <1991Jun4.085032.6141@irisa.fr>
Date: 4 Jun 91 08:50:32 GMT
Article-I.D.: irisa.1991Jun4.085032.6141
References: <1991Jun3.145924.28406@mstr.hgc.edu>
Sender: news@irisa.fr
Organization: IRISA, Rennes (FR)
Lines: 55

From article <1991Jun3.145924.28406@mstr.hgc.edu>, by jcm@mstr.hgc.edu (James McKim):
> 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.

Recalling the link between Algebraic Abstract Data Types and O.O.P, 
I would say that the notions of "generator" and "observer" operations
should have corresponding entities in classes. Generators are used 
to structurally build terms and observers are used to relate them.
Objects can be seen as representations of terms although the 
structure is coded into a state and some information is lost. 
We can identify methods that change the state and methods that do not.
I don't think a dichotomy should exist between procedures and
functions, but between state preservers and state changers. 

 In a parallel framework, this distinction at the language level
together with the interface-body separation allows a separate
compilation scheme that ensures that observers don't change
the "global state" (values and other objects through references;
note that we don't consider acquaintances as part of the state) 
and legitimates the generation of code suitable for exploiting
a safe parallelism within an object. The parallel class-based
language ARCHE we are currently implementing adopts this view.
We provide a symetric concurrent read exclusive write synchronisation
policy at the object interface level. A conditional synchronisation
is also provided at the interface level, but I don't show it here.
  The stack example looks as follows:

TYPE StackT = VIEW 
               Push : (item : INT) ();
               Pop  : () (item : INT)
              OBSERVER
               Top  : () (item : INT);
               Empty: () (maybe: BOOLEAN)
              END;

CLASS ArrayStack IMPLEMENTS Lib.StackT =
 VAR State : SEQ OF INT := <>;
     TopPtr: INT := 0;
 
 PROCEDURE Push  = ... END Push;
 PROCEDURE Pop   = ... END Pop;
 PROCEDURE Top   = ... END Top;
 PROCEDURE Empty = ... END Empty;
END ArrayStack;


--Marc Benveniste                mbenveni@irisa.irisa.fr
IRISA
Campus de Beaulieu
35042 Rennes Cedex
FRANCE