Xref: utzoo comp.lang.eiffel:1649 comp.object:3695
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!rphroy!caen!math.lsa.umich.edu!sharkey!news.iastate.edu!hobbes.physics.uiowa.edu!ns-mx!uunet!ukma!rex!spool.mu.edu!olivea!mintaka!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!mucs!logitek!hrc63!mrcu!paj
From: paj@mrcu (Paul Johnson)
Newsgroups: comp.lang.eiffel,comp.object
Subject: Re: Functions without side effects (was Old confusion)
Message-ID: <956@puck.mrcu>
Date: 10 Jun 91 09:10:10 GMT
References: <130242@tut.cis.ohio-state.edu> <1991Jun5.072556.19870@irisa.fr> <1991Jun5.083241.13145@tkou02.enet.dec.com>
Reply-To: paj@uk.co.gec-mrc (Paul Johnson)
Organization: GEC-Marconi Research Centre, Great Baddow, UK
Lines: 20

>There are degrees of purity.  Idempotency does not imply an absence of
>side effects.  Even a function which is "practically" "pure" should be
>able to signal an error handler on occasion, which is likely to cause
>side effects in both I/O and in the I/O support routines' knowledge of
>the external state.

Why not add a keyword `unchanged' to the `ensure' clause?  This would
be equivalent to something along the lines of `current.equal( old
current )' and would assert that the function has not changed
anything.  Function purity then becomes a run-time checkable
assertion.  Of course it does not handle internal changes (such as the
tree rearangement which someone suggested) but that *is* a little more
complicated.  For functions which simply return some aspect of the
state it would do quite well.

Paul.
-- 
Paul Johnson |            Isn't modern education wonderful: one size fits all!
-------------^------------------v-------------------------v-------------------
GEC-Marconi Research is not 	| Telex: 995016 GECRES G  | Tel: +44 245 73331
responsible for my opinions.	| Inet: paj@gec-mrc.co.uk | Fax: +44 245 75244