Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.society.futures
Subject: Re: C's sins of commission (was: (pssst...fortran?))
Message-ID: <64616@lanl.gov>
Date: 3 Oct 90 00:00:57 GMT
References: <5006@uqcspe.cs.uq.oz.au>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 43

From article <5006@uqcspe.cs.uq.oz.au>, by brendan@batserver.cs.uq.oz.au (Brendan Mahony):
> jlg@lanl.gov (Jim Giles) writes:
> 
>>Oh, well.  If it's a question of side-effects.  I oppose them outright.
>>As a practical matter, you can convince most programmers that operators
>>should not have side-effects.  But, when it comes to functions, they
>>always demand to be allowed side-effects.
> 
> Do they really? Why in the world do they want to make their life so
> difficult? I don't see what side-effects in functions can do that tuple
> valued expressions can't do, execept make the code unreadable and
> impossible to reason about. [...]

I quite agree with what you said.  I don't think that functions
need to be 'tuple valued' - they just need to be able to return
data of _any_ type, including user defined types.  This way, if a
tuple result is needed, the function would be defined as returning
values of some 'record' type (said type describes the tuple).

However, tuples don't solve the function side-effect problem.  There are
three distinct ways a function might have a side-effect: 1) the function
may modify its arguments (which is what the tuple idea would eliminate the
need for); 2) the function may perform I/O or modify global data; 3) the
function may contain internal context which causes its return value to
be dependent on the number of times it's called or the order it recieves
arguments.

Now, some people may disagree with the last two points above and refuse
to use the term 'side-effect' for these features.  I don't want to argue
about it.  From a practical standpoint, all three types of side-effects
inhibit optimization in exactly the same ways.  Such calls can't be
reordered, they can't be eliminated (if they happen to have the same
argument values), and they can't run in parallel.

In any case, the user community seems to regard the ability to have
functions with side-effects as indispensable (and, at least with regard
to random number generators, I tend to agree).  This means that the
language designer must think about this issue very carefully.  I still
support allowing functions to have side-effects - but only if the nature
of their side-effects are clearly described in the 'function prototype'
or 'interface' or whatever you decide to call it.

J. Giles